Intel Fortran Compiler for Mac OS 10.5 Tiger?

Intel Fortran Compiler for Mac OS 10.5 Tiger?

I have some programs that need to be compiled from source using a good Fortran compiler for Mac OS (computational chemistry programs specifically) and I understand that Intel is currently the best option available.

Has anyone tested the current version of the Intel Fotran compiler 10 for Mac OS on a beta (developer) release of Tiger with the new version of XCode?

I do not want to purchase the current student version (as it does not come with updates per my understanding) unless it will work on Tiger as I plan to upgrade shortly.

Any thoughts would be appreciated.

--Thomas

45 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

10.5 is Leopard, isn't it? Apple has asked us not to make any public statements about support for Leopard until they actually announce it, never mind that they've been talking it up and giving away tens of thousands of copies for months.

We of course have been doing our own testing each time a new build is made available, but I would strongly recommend waiting for maybe a month before purchasing. You can download and install the free 30-day trial version while you're waiting.

Steve - Intel Developer Support

Hi Steve,

I tried version 10.0.017 on Leopard and it looks like I have all kinds of error-> libSystem.B.dylib seems to be a problem ...

Is there a beta version of the compiler for Leopard ?

Best regards,

PO Dallaire

The current 10.0 (10.0.020) supports Leopard. We can say that now. If you have problems, please report them to Intel Premier Support.

Steve - Intel Developer Support

Thanks Steve for your reply.

I tried 10.0.020 this morning -> still no success. I reported the bug to Intel Premier Support and they said that I should wait for version 10.1 that will come out next month.

PODallaire

edit : I found my problem, it is with the -ipo flag, looks like there is a slash that breaks the path :

ipo: warning #11041: unresolved _fegetenv

Referenced in /usr/lib//libdl.dylib

ipo: warning #11041: unresolved _fegetround

Referenced in /usr/lib//libdl.dylib

ipo: warning #11041: unresolved _fesetenv

Referenced in /usr/lib//libdl.dylib

ipo: warning #11041: unresolved _nan

Referenced in /usr/lib//libdl.dylib

ipo: warning #11041: unresolved _nanf

Referenced in /usr/lib//libdl.dylib

ipo: warning #11041: unresolved _nextafterf

Referenced in /usr/lib//libdl.dylib

I am running OS X 10.5, and have errors compiling. in both 10.0.016 and 10.0.020, I get the following errors when running my code:

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image PC Routine Line Source

a.out 000585D1 Unknown Unknown Unknown

a.out 00057A73 Unknown Unknown Unknown

a.out 0002E95C Unknown Unknown Unknown

a.out 00010ABE Unknown Unknown Unknown

a.out 00017438 Unknown Unknown Unknown

libSystem.B.dylib 91B0F97B Unknown Unknown Unknown

Unknown FFFFFFFF Unknown Unknown Unknown

a.out 0000256C Unknown Unknown Unknown

a.out 00002499 Unknown Unknown Unknown

Unknown 00000001 Unknown Unknown Unknown

I did not get any of these errors using the previous version of the compiler in OS X 10.4. Also, this is really basic code (it's for a numerical methods for PDE's class), so there is nothing complex or exotic in it.

Thank you,

Alex Pace

I am using a 9.0 version and I get the same type of error compiling a program that worked well with 10.4.9. So something has changed. I wonder if Intel is going to have some updates on this?

You can overcome this problem by downloading version 10 and using the /opt/intel/fce version instead of the /opt/intel/fc/ version. /fce is the 64 bit version.

asafaein:I am using a 9.0 version and I get the same type of error compiling a program that worked well with 10.4.9. So something has changed. I wonder if Intel is going to have some updates on this?

There will be no more 9.0 updates. Please use version 10.0. Some users have experienced problems with 10.0 on Leopard - an update coming in the next few weeks should help with that. Please contact Intel Premier Support for more assistance.

Steve - Intel Developer Support

I am getting exactly the same problem as a.e.pace. Using either Fortran version 9 or 10 compiled under Tiger does not run under Leopard. Downloading 10 on the leopard system compiles ok (but only works with sudo due to not being able to create tmp file error, that's another issue) but with a wide variety of compiler/linker options generates the same SIGSEGV segmentation fault error. Every binary shows the problem.

It would be great if Intel support could sort this out soon. For now I have to discourage users from upgrading to Leopard.

Are you saying that you compile a binary under Tiger and move it onto a Leopard system to run? I would not recommend that combo.

for 10.0.020 native on Leopard:
avoid -ipo option
source /opt/intel/fce/10.0.020/bin/ifortvars.sh prior to build and run.
Use the -heap-arrays option
And try -m64 as a last resort.

10.1 is our first compiler that supports Leopard. Again, we all have to wait a little while. The above may help, but no guarantees.

ron

I am facing problem under Leopard even, with latest intel compilers 10.1 (downloaded this morning). I still have problem when using lam-mpi

1) lam-mpi can't be configured new icc and icpc 10.1.006 but can be configred using gcc and ifort 10.1.006.

2) once configured, I am facing problem to link program with lam-mpi

for instance, the program example.f90

program qui_je_suis

implicit none

include 'mpif.h'

integer :: nb_procs,rang,code

call mpi_init(code)

call mpi_comm_size(MPI_COMM_WORLD,nb_procs,code)

call mpi_comm_rank(MPI_COMM_WORLD,rang,code)

print *,'Je suis le processus ',rang,' parmi ',nb_procs

call mpi_finalize(code)

end program qui_je_suis

if I compile it:

mpif77 example.f90

gives:

Undefined symbols:

"_lam_f77init", referenced from:

_lam_f77init$non_lazy_ptr in liblamf77mpi.a(init_f.o)

"_lam_darwin_malloc_linker_hack", referenced from:

"_lam_F_handles", referenced from:

_lam_F_handles$non_lazy_ptr in liblamf77mpi.a(crank_f.o)

_lam_F_handles$non_lazy_ptr in liblamf77mpi.a(csize_f.o)

ld: symbol(s) not found

Yes, same thing here, mpi does not work with ifort and Leopard. I recompiled openmpi, tried to re-run my codes and several errors occured.

I can try a build with 10.1 and OpenMPI on Leopard. I'll report back on my findings.

ron

Ron

I have tried it both ways. Compile under Tiger doesn't work except on Tiger. Compile under Leopard also a non-starter yesterday. I will retry with your suggested options when I get back to my Leopard system on Sunday.

Thank you for your help!

Cheers

Mike

I think I'm hot on the trail of this bug. Yes, it does only seem to affect Leopard systems.

In the configure script, LANGUAGE env var is set to LANGUAGE=C. This in a loop around line 105.

If you insert a new line at 116, and put in

unset LANGUAGE

the configure will complete and life is good. I suspect lam-mpi is doing the same setting of LANGUAGE, since Open MPI evolved from lam.

The final failure comes about in line 5533, where the ICC compiler attempts to compile a simple source file.

You can also try setting LANGUAGE=C at the command line and get the same failure with icc when you try to compile source files.

So use this work around whilst I try to find out what broke with LANGUAGE=C on Leopard.

cheers

ron

Another interesting discovery, this seems to only fail for root. Were you logged in as root when you tried your openmpi build? I was.

I have a similar problem trying to get netcdf-3.6.2 to work on MacOSX 10.5 with ifort 10.1.006. If I compile it normally and then try out a test f90 program, I get the following at runtime:

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image PC Routine Line Source

test 000E52B7 Unknown Unknown Unknown

test 000E4753 Unknown Unknown Unknown

test 000BB430 Unknown Unknown Unknown

test 000992CA Unknown Unknown Unknown

test 0009FC30 Unknown Unknown Unknown

libSystem.B.dylib 93C4797B Unknown Unknown Unknown

Unknown FFFFFFFF Unknown Unknown Unknown

test 00003212 Unknown Unknown Unknown

test 00002382 Unknown Unknown Unknown

test 0000233C Unknown Unknown Unknown

test 00002269 Unknown Unknown Unknown

Unknown 00000001 Unknown Unknown Unknown

If I recompile netcdf and the test program (in nf_test/tst_f90.f90) using debug (-g), then it all works just fine. there is a problem with the runtime of 10.1.006 it appears.

I have submitted a support ticket to see if we can't track it down.

Doing some more digging, I created a very simple test program. Copy the following into a file, ifc_test.f90. Compile using:

ifort ifc_test.f90

Run a.out, and it will crash with the errors I listed in the previous message at TEST_FIVE. It appears when assigning a vector array.

program ifc_test

implicit none

integer :: test_one

integer, dimension(2) :: test_two

integer, dimension(2) :: test_three

real*4, dimension(2) :: test_four

real*4, dimension(4) :: test_five

print *,'WELCOME'

test_one=4

print *,'TEST_ONE=',test_one

test_two(1)=5

test_two(2)=7

print *,'TEST_TWO=',test_two

test_three=(/ 6, 8 /)

print *,'TEST_THREE=',test_three

test_four=(/ -4.2, 7.6 /)

print *,'TEST_FOUR=',test_four

test_five = (/ -90.0, -87.5, -85.0, -82.5 /)

print *,'TEST_FIVE=',test_five

end program ifc_test

Please report this issue to Intel Premier Support. I'm aware that there's a problem recently discovered for applications running on Leopard that you may be encountering. Support can tell you if this is the same issue and when an update is available.

Steve - Intel Developer Support

I encounter exactly the same problem.

Did you find a workaround aside from compiling with -g

Thanks,
Bernard.

I have a workaround for some of the SIGSEGV, segmentation fault problems. If you save program input files in DOS format, and then run programs using these DOS-formatted input files, the SIGSEGV faults are partly overcome. In a long input file I still hit the problem. Saving in MAC (or I suppose Unix) format seems to elicit the SIGSEGV bug. I write this to alert the programmers to this Leopard-only problem.

I'm also having this SIGSEGV problem with 32-bit version of ifort on Leopard, even with the new 10.1 compiler version. And I can't use the /fce/ compiler because it doesn't work on my macbook core duo (32bit).

I am having exactly the same problem. I have tried various compiler options (turning off optimization) etc., but with no luck. I always get a SIGSEV on my macbook dual core with Leopard and Intel Fortran Compiler 10.1.006.

Cheers, Trond

10.1.007 should be available now - try that.

Steve - Intel Developer Support

Good morning Steve,

I tried 10.1.007 version and made tow tests :

1) Compile and run a standard Fortran code that read and write files and that does not link to an external library;

2) Compile f90gl librarires and compile/run a Fortran code that uses f90gl.

Task 1 passed but I saw that reading files from a mounted network drive did not work. For task 2, I have this error that I had since I'm running Leopard :

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image PC Routine Line Source

sppr 0005B117 Unknown Unknown Unknown

sppr 0005A5B3 Unknown Unknown Unknown

sppr 00031634 Unknown Unknown Unknown

sppr 00011544 Unknown Unknown Unknown

sppr 000182AE Unknown Unknown Unknown

libSystem.B.dylib 9006F97B Unknown Unknown Unknown

Unknown FFFFFFFF Unknown Unknown Unknown

sppr 00022921 Unknown Unknown Unknown

sppr 00002A57 Unknown Unknown Unknown

Regards,

Pierre-Olivier

Please submit a test case to Intel Premier Support.

Steve - Intel Developer Support

Does anyone know if the issue below has been resolved yet. I am having the same problem using intel fortran 10.1.007 on Mac OS 10.5 (Leopard).

Thanks.

Lanre

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image PC Routine Line Source

sppr 0005B117 Unknown Unknown Unknown

sppr 0005A5B3 Unknown Unknown Unknown

sppr 00031634 Unknown Unknown Unknown

sppr 00011544 Unknown Unknown Unknown

sppr 000182AE Unknown Unknown Unknown

libSystem.B.dylib 9006F97B Unknown Unknown Unknown

Unknown FFFFFFFF Unknown Unknown Unknown

sppr 00022921 Unknown Unknown Unknown

sppr 00002A57 Unknown Unknown Unknown

Lanre,

What you have shown is an error message, not an issue. There are many, MANY possible causes of a segmentation fault, some of which are programming errors in the application. We'd need to see the program that generated this error to tell you if it is an issue in the compiler and whether or not it is resolved. If you have a test case, please submit it to Intel Premier Support and we'll be glad to take a look.

Steve - Intel Developer Support

Same issues here with v. 10.1.006 and Leopard 10.5.2.

In the meantime, I compiled my codes with gfortran. Will this issue be ever addressed ? (because this thread is quite old now)

TIA

What "same issues"? This is a long thread with a variety of issues, some of which are coding errors.

Steve - Intel Developer Support

Hi,

From my side I still have problems (libSystem crashes) when trying to compile f90gl, library that I was able to compile before under Tiger with ifort. I get :

libSystem.B.dylib 9479C5EB Unknown Unknown Unknown

when compiling this :

../util/sppr fwrap.f90

I tried everything - I don't know what to do.

Thanks

PO

Report the problem to Intel Support and include everything needed to reproduce the problem. Make sure that you identify the compiler version as well (10.1.012 is current).

Steve - Intel Developer Support
MADsblionel:What "same issues"? This is a long thread with a variety of issues, some of which are coding errors.

SIGSEGV while accesing libSystem.B.dylib

Hard to narrow down the issue but I have the feeling it has to do with accessing stdin or stdout

Random example : the following program now crashes, it was fine with OSX 10.5.1.

program H3_JA

implicit real*8(a-h,o-z)

read(*,*) rr,r,th

pi=acos(-1.d0)

x1 = 0.

y1 = 0.

z1 = 0.

q1 = 1.

x2 = r-rr/2.*cos(th*pi/180.)

y2 = rr/2.*sin(th*pi/180.)

z2 = 0.

q2 = 1.

x3 = r+rr/2.*cos(th*pi/180.)

y3 = -rr/2.*sin(th*pi/180.)

z3 = 0.

q3 = 1.

x4 = 0.

y4 = 0.

z4 = 0.

q4 = 0.

if(abs(th).lt.1.d-5) then

y1 = 0.

y2 = 0.

y3 = 0.

end if

write(*,'(9(f10.6,2x))') x1,y1,z1,x2,y2,z2,x3,y3,z3

end

Forgot to mention that in some cases, switching to the fce distribution does solve the problem.

So I guess it would be nice to clarify when to use fc, when to use fce, why, etc

Re: fc vs. fce:

fc generates 32-bit code, fce generates 64-bit code. That's it. If you're seeing problems when updating MacOS versions, that suggests a bug in MacOS. It would be most interesting to know if the error occurs if you DON'T rebuild the application. Those dylibs in the error messages are Apple's, not ours.

Steve - Intel Developer Support

To follow Steve's comments, I would like to add a few points.

- As Steve said, segmentation faults can occur for many many reasons, coding errors, insufficient stack space in the user environment, etc.

- You are using a the 10.1.006 version of the compiler. This was released back in November. Since then there have been 3 more compiler updates, with another due near the end of this month. Registered users go to:

https://registrationcenter.intel.com

to download the latest compiler updates. This applies to evaluation customers too, who have 30 days of access to registrationcenter. I would recommend this - you are using Leopard and .006 was the first compiler to support Leopard. There have been many improvements to the compiler for Leopard in these updates.

Take some time to read through the forum. There are multiple notes on segmentation violation, albeit on Linux. The same Linux concepts apply to Mac OS. And of course, use the 64bit compiler (if you have a 64bit Mac) and try options:

-g -traceback -check all

to help isolate the fault.

ron

OK, I found a good example. I dug up an old code which I compiled under 10.5.0 I think Run it as it is, without rebuilding it, and it runs OK.

make clean; make (using fc) --> SIGSEGV in libSystem.B.dylib

make clean; make (using fce) --> Runs OK.

Should I conclude that the fc distribution is kinda broken with 10.5.2 ?

IMHO, you should anyway advertise more on these 2 versions of the compiler : I learnd about this fce thingy reading this thread :D

No, your test does not necessarily mean that the compiler is broken. Please do submit an example to support so that it can be investigated.

Have you read the product release notes or documentation?

Steve - Intel Developer Support
MADsblionel:Please do submit an example to support so that it can be investigated.

Well, there is always the little program I have posted above

So, I've installed version 10.1.012 and at first glance, it seems to solve the SIGSEGV problem. I'll continue testing it.

Thanks for the help.

Almost forgot this thread :D

I now have installed 10.1.014 and still have this SIGSEGV error on some of my codes; codes which I since have compiled with gfortran and which run fine (the reason I forgot this thread. Didn't look into this more deeper)

Hopefully, my production machine under OSX 10.4 with ifort 9.1.036 runs like a charm. Since it is a production machine, I don't upgrade anything ! :D

What's that saying ? If it ain't broken, don't fix it. :)

My legacy application is compiled with ifort 10.1 Build 20070913

on MACOSX 10.5.2. I get a SIGSEGV, segmentation fault as soon

as my code try to use an array allocated by malloc in a C function called by the code. I reported the bug to Intel (Issue number: 478952) with a simple code to reproduce the bug, but I am unable to consult my issue report as the website https://premier.intel.com produces a HTTP 500 - Internal Server Error.

What can I do now? Any idea? I had similar problems with Absoft, 15 years ago but at least they were responding.

Alain Hebert

professor

The Intel Premier Support site works for me at the moment.

I'd suggest getting the current compiler version as the one you have has had issues on Leopard.

Steve - Intel Developer Support

I found the problem and my code is working fine now. Here is the problem: I first install Build 20080312 from the DVD Intel sent me. Doing "ifort -V" returned "Intel Fortran Compiler for applications running on Intel I32". Next, I reinstalled the SAME build from the Intel Website. Now, "ifort -V" is returning "Intel Fortran Compiler for applications running on Intel 64" and everything is working! Note that I am always using the "-m32" switch in my configuration scripts. There is something I miss in the installation process.

Intel compilers don't observe the -m32 switch, which selects gnu 32-bit compilation and linking. Intel 32- or 64-bit compilers are installed in separate directories, selected by setting environment variables, as by the corresponding ifortvars and iccvars scripts. gcc -m32 will work in mixed builds only with the ifort 32-bit.

Leave a Comment

Please sign in to add a comment. Not a member? Join today