Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Rhys_Ulerich
New Contributor I
118 Views

icpc 10.1 version 20081024 to 20080602: assuming all members of group ... are COMDAT

Jump to solution

On one system, I am using icpc 10.1 release 20081024 to build an application. Both -O0 and -O3 run correctly. My 20081024 build output contains warnings like

/tmp/icpcMFefDdas_.s: Assembler messages:
/tmp/icpcMFefDdas_.s:1746124: Warning: assuming all members of group `_ZNK8suzerain9underling4plan26execute_long_n2_to_long_n1Ev' are COMDAT

On another system, I am using icpc 10.1 release 20080602 to build the same application. The build for -O0 runs correctly but -O3 dies mysteriously*. No such COMDAT assumption warnings are emitted by the 20080602 compiler.

Is it possible that the difference is related to this assembler warning? Does anyone have background documentation on the warning and its implications?

Thanks in advance,

-Rhys

mysteriously* = FFTW 3.3 w/ threading and MPI-enabled inexplicably returns a NULL fftw_plan. I say mysteriously because the same FFTW 3.3 shared library is being linked against for the working and non-working case and the requested fftw_plan is identical. I can isolate the problem to how my code is built. FWIW, this -O3 problem atop 20080602 did not start until I started using FFTW 3.3's OpenMP-based threading.

0 Kudos
1 Solution
Dale_S_Intel
Employee
118 Views

Well, if it is a bug in the compiler, you'd need to upgrade to a newer newer one to get a fix, so I'm not sure how practical it would be to try to find a bug that's apparently fixed some time back in the compiler. You could try to isolate the file and build just that file with -O0, or even use "pragma optimize" if you can isolate it to a single function. I wouldn't expect the COMDAT warning to be a problem, but mpi is not my forte. Of course it may not be a compiler issue, so it might be worth trying to trace the problem back in the debugger, but I know that can be painful.

Can you build your code on the system were you have the newer compiler and copy it back to the other one? I think since they're both 10.1 compilers that should be safe.

Dale

View solution in original post

4 Replies
Rhys_Ulerich
New Contributor I
118 Views
Oh-- the obvious try 20081024 in the breaking environment isn't possible, it's a managed HPC platform that I don't control.
Rhys_Ulerich
New Contributor I
118 Views
Turns out that building my application with -O1 or -O2 on 20080602 also dies the same mysterious death as -O3. As stated before, -O0 on 20080602 works. Can anyone suggest relevant diagnostics?
Dale_S_Intel
Employee
119 Views

Well, if it is a bug in the compiler, you'd need to upgrade to a newer newer one to get a fix, so I'm not sure how practical it would be to try to find a bug that's apparently fixed some time back in the compiler. You could try to isolate the file and build just that file with -O0, or even use "pragma optimize" if you can isolate it to a single function. I wouldn't expect the COMDAT warning to be a problem, but mpi is not my forte. Of course it may not be a compiler issue, so it might be worth trying to trace the problem back in the debugger, but I know that can be painful.

Can you build your code on the system were you have the newer compiler and copy it back to the other one? I think since they're both 10.1 compilers that should be safe.

Dale

View solution in original post

Rhys_Ulerich
New Contributor I
118 Views

Thanks for the suggestions Dale.

I've been trying to use the 20081024compiler's diagnostics on the working system to identify anything suspicious in my code. I'm concerned that somehow I've stumbled onto undefined behavior in the language that has changed between the versions. Nothing suggestive has popped up using "-Wall -Wcheck -Weffc++ -Wpointer-arith -Wabi". The source code analysis backend dies. :) Any suggestions for things to try would be much appreciated.

Reply