Not sure if it's the same compiler version, but at least "back then"
when I last played with icc on IA64, the compiler always died as soon as
you has a a reference to an sse-type (__m128 &).
Cheers,
Ingo
Abe Stephens wrote:
> It is clear that no one has built in IA64 for quite some time:
>
> The problem in CPUTime.cc (appearing in both icc and gcc) is due to
> non-portable assembly code being used. I'm not sure where CPUTime is
> used, possibly in the deadline image traverser. I also discovered
> compilation problems in TesselatedCylinder (vla/pod error) and other
> new code.
>
> It appears that some code in RayPacket.h causes the IA64 icc to
> segfault. It appears to be SSE related as the files compile if SSE is
> disabled. This might take some time to track down (by enabling
> MANTA_SSE and then explicitly disabling it for different sections of
> the header).
>
> I'd like very much for Manta to continue to build on Altix/SSE, but I
> don't have a large number of free cycles right now to find the
> offending code. It's likely that there is some intrinsic which is
> causing the issue and could be inclosed in a #if __ia64__ block.
>
> If you could help isolate where it is, I will certainly help fix it
> where it occurs.
>
> Abe
>
> On Aug 23, 2007, at 12:47 PM, Christian Odom wrote:
>
>>
>>
>> On 8/23/07, *Abe Stephens* <abe@sci.utah.edu
>> <mailto:abe@sci.utah.edu>> wrote:
>>
>>
>> Which source file causes the icc internal error? It looks like
>> icpc 9.0 segfaults when compiling CheapRNG.cc. (Unfortunately I
>> don't have icc ia64 10.0 here...)
>>
>> Here is the output from make->
>> //////////////////////////////////////////////////////////////////////////////
>> [ 13%] Building CXX object Core/CMakeFiles/Manta_Core.dir/Math/CheapRNG.o
>> (0): internal error: backend signals
>>
>> compilation aborted for /store/toolkit/Manta/Core/Math/CheapRNG.cc
>> (code 4)
>> make[2]: *** [Core/CMakeFiles/Manta_Core.dir/Math/CheapRNG.o] Error 4
>> make[1]: *** [Core/CMakeFiles/Manta_Core.dir/all] Error 2
>> make: *** [all] Error 2
>> //////////////////////////////////////////////////////////////////////////////
>> It still seems to be CheapRNG
>>
>> The gcc problem is certainly fixable by using separate code on
>> IA64. Back in the day icc was much, much faster than gcc--I'd
>> imagine that is still the case today. Let's try to figure out
>> what code is causing problems with icc before switching to gcc.
>>
>> Abe
>>
>> On Aug 23, 2007, at 12:10 PM, Christian Odom wrote:
>>
>>> Hi guys
>>>
>>> Im running into a couple of compile errors on our ia64 platforms
>>> when trying to compile Rev: 1678.
>>>
>>> With icc 10.0 we are still getting the dreaded->
>>> (0): internal error: backend signals
>>> //////////////////////////////////////////////////////////////////////////////
>>>
>>>
>>> When using gcc 4.1.2 Im getting this mess->
>>>
>>> /store/toolkit/Manta/Core/Util/CPUTime.cc: In static member
>>> function `static
>>> long long unsigned int Manta::CPUTime::currentTicks()':
>>> /store/toolkit/Manta/Core/Util/CPUTime.cc:90: error: impossible
>>> register
>>> constraint in `asm'
>>> /store/toolkit/Manta/Core/Util/CPUTime.cc:90: error: impossible
>>> register
>>> constraint in `asm'
>>> /store/toolkit/Manta/Core/Util/CPUTime.cc:90: error: impossible
>>> register
>>> constraint in `asm'
>>> /store/toolkit/Manta/Core/Util/CPUTime.cc:93: error:
>>> unrecognizable insn:
>>> (insn 28 40 55 2 0x2000000001631860 (parallel [
>>> (set (reg:SI 2 r2)
>>> (asm_operands/v:SI ("rdtsc") ("=a") 0 []
>>> [] ("/store/toolkit/Manta/Core/Util/CPUTime.cc") 90))
>>> (set (reg:SI 15 r15)
>>> (asm_operands/v:SI ("rdtsc") ("=d") 1 []
>>> [] ("/store/toolkit/Manta/Core/Util/CPUTime.cc") 90))
>>> ]) -1 (insn_list:REG_DEP_ANTI 15 (insn_list 14 (insn_list 12
>>> (insn_list 10 (insn_list 20 (nil))))))
>>> (nil))
>>> /store/toolkit/Manta/Core/Util/CPUTime.cc:93: confused by
>>> earlier errors, bailing out
>>> gmake[2]: *** [Core/CMakeFiles/Manta_Core.dir/Util/CPUTime.o]
>>> Error 1
>>> gmake[1]: *** [Core/CMakeFiles/Manta_Core.dir/all] Error 2
>>> gmake: *** [all] Error 2
>>> //////////////////////////////////////////////////////////////////////////////
>>>
>>> I dont know if there is any hope for the icc compiler, but any
>>> thoughts on the gcc issue would be awesome.
>>> --
>>> Christian Odom
>>> Graduate Student
>>> Center for Advanced Computer Studies
>>> http://www.cacs.louisiana.edu < http://www.cacs.louisiana.edu>
>>> Louisiana Immersive Technologies Enterprise
>>> http://www.lite3d.com
>>
>>
>>
>>
>>
>> --
>> Christian Odom
>> Graduate Student
>> Center for Advanced Computer Studies
>> http://www.cacs.louisiana.edu
>> Louisiana Immersive Technologies Enterprise
>> http://www.lite3d.com
>
>
Archive powered by MHonArc 2.6.16.