anyone have experience with icc on linux?

[jhu]

i have debian 3.1 running on my athlon 64 system. it's a fully 64-bit system with 32-bit emulation in the kernel. i just have a couple issues:

1) when i compile a program i can't get it to run except when it's compiled statically, which isn't a big deal. however, i can't tell whether it's using a 64-bit code path or a 32-bit code path. this issue came up because it's able to run in the native 64-bit environment and in a chrooted 32-bit environment. i guess the next step would be to compile the linux kernel without 32-bit support

2) compiled programs run with the -xW option. however with the -xP option, i get a program message saying my processor isn't the right type, which doesn't make any sense. the -xP option also uses sse3 instructions. however my athlon 64 processor does support sse3 instructions. is there some way to bypass the message and have the code path run regardless?

 

[cleverhandle]

Originally posted by: jhu
when i compile a program i can't get it to run except when it's compiled statically, which isn't a big deal.

Uhh... not having shared library support isn't a big deal? Seems to indicate a serious misconfiguration to me. Is this true for any program you compile or just for a specific one?

however, i can't tell whether it's using a 64-bit code path or a 32-bit code path. this issue came up because it's able to run in the native 64-bit environment and in a chrooted 32-bit environment.

file /path/to/program should tell you what kind of executable you're dealing with.

2) compiled programs run with the -xW option. however with the -xP option, i get a program message saying my processor isn't the right type, which doesn't make any sense. the -xP option also uses sse3 instructions. however my athlon 64 processor does support sse3 instructions. is there some way to bypass the message and have the code path run regardless?

There's more to compiler optimization than the instruction set - an Athlon can't run P4-optimized SSE3 code (or at least, would run it poorly). Given that it's an intel compiler, it shouldn't be a big surprise that they're not providing optimizations targetted at A64's. Why is it that you want to use icc instead of gcc anyway?

 

[jhu]

Originally posted by: cleverhandle
Uhh... not having shared library support isn't a big deal? Seems to indicate a serious misconfiguration to me. Is this true for any program you compile or just for a specific one?

i'm only using icc for a specific program (povray), so having it statically linked isn't a big deal. i use gcc for everything else.

file /path/to/program should tell you what kind of executable you're dealing with.

hmm... forgot about that one. interestingly, the compiled program is 64-bit, however iccbin (the compiler itself) is a 32-bit program. i wonder why they didn't make it 64-bit native?

There's more to compiler optimization than the instruction set - an Athlon can't run P4-optimized SSE3 code (or at least, would run it poorly). Given that it's an intel compiler, it shouldn't be a big surprise that they're not providing optimizations targetted at A64's. Why is it that you want to use icc instead of gcc anyway?

but an athlon 64 should be able to run p4-optimized sse3 code. i suspect the code is checking cpuid and not executing if it's not an intel processor with sse3, which somewhat makes sense since the first opterons didn't have sse3. however, now they do. i did read somewhere on slashdot that this could be bypassed somehow, but now i can't find it.

ok, found the slashdot article and the patch to fix the problem. interestingly, i just patched my icc installation, and the -xP option now works.