Internal read statement causing errors on OSX 64-bit

[otte]

I've been trying unsuccessfully to run the weather research and forecast model (WRF) on OSX 10.6.3 with the latest two Intel fortran compilers (11.1.084 and 11.1.088). I have narrowed the problem down to an internal read statement that is corrupting other arrays within the program. Here is a very simple example, which I will cut-and-paste here as well as attach to this message:

program test

implicit none

character(len=4) :: odate

integer :: year

integer :: iarray(5)

iarray(1) = 1

iarray(2) = 2

iarray(3) = 3

iarray(4) = 4

iarray(5) = 5

odate = '2005'

! This next line seems to be corrupting iarray on OSX 64-bit:

read(odate, '(I4)') year

write(*,*) odate, " successfully converted to:", year

write(*,*) "Integer array should be:"

write(*,*) (/ 1, 2, 3, 4, 5 /)

write(*,*) "but instead is:"

write(*,*) iarray

end program test

When I compile this program on snow leopard, the internal read statement causes the iarray variable to become corrupted:

> ifort test.f90

> ./a.out

2005 successfully converted to: 2005

Integer array should be:

1 2 3 4 5

but instead is:

54 36 1 4 5

This same example seems to work fine on linux and on OSX snow leopard if I compile for 32-bit, but not the default OSX 64-bit compile.

Please see if you can verify this behavior with the latest Intel compilers, unless there is a problem with my OSX setup.

Thanks for your help,

Martin

[Ron_Green]

A blatant bug. I will open a bug report.

This occurs at -O1 and above. -O0 will avoid, but I understand that is not an option for WRF.

bug report ID DPD200154288

ron

[otte]

The error also shows up if you do an internal write to a character string. For example, in the example code I gave, if you instead write from the integer "year" to the internal character string "odate", the same problem occurs on OSX 64-bit:

year = 2005

! This next line seems to be corrupting iarray on OSX 64-bit:

write(odate, '(I4)') year

WRF uses internal read/writes frequently, so I hope you can track down this bug soon.

Martin

[Ron_Green]

The bug was entered as the highest criticality. Unfortunately, we JUST missed the last update, Update 6, which was posted last week. Our next update is tendatively scheduled for August, so it will be a while until a fixed compiler can be posted. We do not do out of cycle patches.

I'm trying to determine if this is isolated to Snow Leopard and/or IF an older compiler may not have the bug.

ron

[Ron_Green]

Martyn,

Perhaps some good news: the compiler itself is fine. And I've determined that the OS X upgrade to 10.6.3 is fine also. It was the Xcode update from 3.2.1 to 3.2.2 that causes the problem. When they went to 3.2.2 they inserted an new build of gcc 4.2.1 (5659). You can see the difference:

OLD: Mac 10.6.3 Xcode 3.2.1
g++ --version
g++ --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)

$ otool -L ./test
g++ --version
g++ --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
./test:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 246.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 315.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
$ ./test
2005 successfully converted to: 2005
Integer array should be:
1 2 3 4 5
but instead is:
1 2 3 4 5


NEW xcode: Mac 10.6.3 Xcode 3.2.2
$ otool -L ./test
./test:
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 438.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 315.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.0.1)
$ ./test
2005 successfully converted to: 2005
Integer array should be:
1 2 3 4 5
but instead is:
54 36 1 4 55



SO the good news - IF you reinstall Xcode 3.2.1 so that /usr/lib is populated with the OLDER gcc build and libraries you should be fine using the 11.1.088 compiler.

We'll get a fix for Xcode 3.2.2 and I'll make sure to warn folks that Xcode 3.2.2 is not supported (which it's not at this time, nor is Mac OS X 10.6.3 (the Release notes say 10.6.2 and Xcode 3.2.1) )

ron

[otte]

Yes, I had upgraded to Xcode 3.2.2 and this was the cause of the problem. It looks like Xcode 3.2.2 installs a new linker, which may be the cause of the problem. When I copied the previous ld from a machine that still has Xcode 3.2.1 and put it in my PATH, ifort again worked as expected.

Thanks for identifying Xcode 3.2.2 as the problem.

[Ron_Green]

same ashttp://software.intel.com/en-us/forums/showthread.php?t=73942

fix is to use repaired Mac OS X linker included in Xcode 3.2.5 or greater.