ifort options -g, -O, -heap-arrays together cause compiler segmentation fault

[pbro1]

Hello,

I run into an ifort compiler segmentation fault when compiling my program. I managed to condense it down to a test case, test.f90 and List_manip.f90.

$ ifort -O -g -heap-arrays -m64 -c -o test.o test.f90
$ ifort -O -g -heap-arrays -m64 -c -o List_manip.o List_manip.f90
: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.

compilation aborted for List_manip.f90 (code 3)

You'll notice that the files are still pretty extensive, as I did not manage to reproduce the segfault when removing much more. In fact, removing any single one of the allocatable arrays in test.f90, line 150ff will remove the segmentation fault.

The segfault disappears, when one adds -check all to the compile options. Strange...

Compiler version 11.1.087, ifort (IFORT) 11.1 20100806

 

[Ron_Green]

Which version of Xcode? And which version of Mac OS X.

My recent 12.0 Mac compiler and Xcode 4 compile this just fine, as does my Linux system with the 11.1 compiler built onthe same date as yours,20100806.

It may be a combination of that 11.1 compiler, the Xcode and Mac OS version that is needed to reproduce this.

ron

[staghind]

Each time a description of the change, there is always plenty to talk about around the world. They are not exempt. A statement usually is: "i have to change almost immediately versions, so do not expect me to date continue to attack



stagy

[Ron_Green]

Lost in translation, I don't understand your response. For me to reproduce this, I need:

Xcode version?
Mac OS X version?

thanks

ron

[Steven_L_Intel1]

I don't understand stagy's response either, but he (?) is not the one who reported the problem.

[jimdempseyatthecove]

In your test program you have a type named "map"
Can you rename this to a different name "myMap" then replace elesewhere accordingly?

The compiler should be able to disambiguate your type name map with the reserve word map provided that "use new_types" is used or not used according to how you want to interprete "map". By naming your types with names that do not conflict with predefined compiler keywords you avoid this potential problem.

Jim Dempsey

[pbro1]

Sorry for not replying earlier - Easter break.

Quoting Ronald W. Green (Intel)

Which version of Xcode? And which version of Mac OS X.

Xcode 3.2.2 (1650)

Mac OS X 10.6.6

[pbro1]

Quoting jimdempseyatthecove

In your test program you have a type named "map"
Can you rename this to a different name "myMap" then replace elesewhere accordingly?

The compiler should be able to disambiguate your type name map with the reserve word map provided that "use new_types" is used or not used according to how you want to interprete "map". By naming your types with names that do not conflict with predefined compiler keywords you avoid this potential problem.

Jim Dempsey

Hi Jim,

thank you very much for your hint; that indeed fixed the compiler segfault. I would have hoped that -warn all would have alerted me to my folly, though.

Also, thanks to all the other contributors.

Peter Brommer

[Steven_L_Intel1]

Fortran has no reserved words. If the name of a variable is causing a compiler error, that would be a compiler bug.

[Ron_Green · Accepted solution]

Peter,

OK, I have been able to see this segfault on a Mac OS X 10.6.6, Xcode 3.2.2 and 11.1.x testbed. BUT it doesn't affect 12.0 compilers.

I think your compiler version/build information was not quite right: I think you meant you have 11.1.089 build 20100806, aka 11.1 Update 7: http://software.intel.com/en-us/articles/intel-compiler-and-composer-update-version-numbers-to-compiler-version-number-mapping/

But more good and bad news: it does seg fault for recent and old 11.1.0xx compilers. EXCEPT, it appears, 11.1 Update 6, aka 11.1.088 build 20100401 does NOT segfault and does compiles the code.

A couple of choices here: you can downgrade or use the 088 version:
source /opt/intel/Compiler/11.1/088/bin/ifortvars.sh intel64

OR upgrade to 12.0

I can put a bug report in on 11.1 for this, but at this time we don't have any new updates to 11.1 on our calendar.

ron

[pbro1]

Ron,

thanks for your reply.

My compiler version is indeed 11.1.089, sorry for the typo.

I don't really see a purpose to filing a bug report for a version for which no more updates are planned. And as 11.1.088 has issues with the Xcode version installed here (see http://software.intel.com/en-us/forums/showthread.php?t=73942), I will try my luck with the 12.0 compiler.

Peter

[Ron_Green]

Peter,

I must strongly recommend upgrading Xcode to 3.2.5 or greater along this upgrade of the compiler. I checked, the 11.1 and Xcode 3.2.5 do work together but have the same Internal Compiler Error as 3.2.2+11.1.

The newer 11.1.x compilers did have a fix for the Xcode 3.2.2, 3.2.3 and 3.2.4 linker bug/changes BUT there are still some boundary cases and unresolved issues with the Apple ld linker in these versions. We (and others) put in bug report(s) to Apple to address these issues and they responded with a fix to their linker in 3.2.5. So we consider that and newer versions 'safe'.

I forked over the $5 for Xcode 4.0 in the new Mac App Store. I'm using this with 12.0 Update 3 and have been pretty happy with this combo. There is an annoying warning with this combo:

$ ifort hello.f90
ld: warning: -macosx_version_min not specificed, assuming 10.6

This is because there is a linker option -macosx_version_min that the new linker is trying to get us to specify. You can get around this by passing that option to the linker:

ifort -Wl,-macosx_version_min,10.6 hello.f90

and hopefully we'll work around this new change in a future update OR you can just turn a blind eye to the warning.

But definitely get up to Xcode 3.2.5 at a minimum. Although the release notes don't say this, Xcode 3.2.5 + recent 11.1.x compilers work together just fine. And of course 3.2.5 works with 12.0 Update 3.

ron

[pbro1]

Upgraded to Xcode 4.0.2, Intel Compiler 12.0.3 20110309 -> problem resolved.

Thank you all,

Peter

[Steven_L_Intel1]

12.0.4 is now available.