Compiler bug for integer arrays?

[dantzig]

Hello,

I am using ifort 11.1 under MacOS 10.6.3. There is a very strange compiler "feature" when using integer arrays. The following program gets the right answer using gfortran and absoft compilers. It gets the wrong answer when compiled using ifort. (The output of the last 4 numbers is a repeat of the first 4). If I reverse the order of the array, i.e., make connect(2,4) and change the assignments accordingly, it gets the correct answer.

Any thoughts on this?

Thanks,

Jon

program wtf
implicit none

integer :: connect(4,2),i,j

connect(1,1) = 1
connect(2,1) = 2
connect(3,1) = 4
connect(4,1) = 5
connect(1,2) = 2
connect(2,2) = 3
connect(3,2) = 5
connect(4,2) = 6

do j=1,2
do i=1,4
write(*,*)'connect(',i,',',j,') = ',connect(i,j)
enddo
enddo

end

[mecej4]

It happens once in a while that a user creates a new copy of a source file in a different folder, but the IDE continues to work with the old version of the source file. Until one realizes this, it can be exasperating since one keeps fiddling with the code in the editor but the changes seem to do nothing to the compiling and running!

A mature compiler such as Ifort cannot survive on the market if it cannot handle a trivial piece of code such as this. Ifort 11.1 on Linux compiled and ran it with no errors.

[dantzig]

I have made multiple copies, and continued reducing the code until I got to this trivial version. I suppose you can imagine how the program got its name.

Jon

[jimdempseyatthecove]

This sounds like it is more of an IDE issue than an ifort issue.

I am a new user to Linux and Eclipse, I have been using VS for... well since it came out, and Borland IDE prior to that. I noticed in Eclipse that the default is if you make a change to a source file, that build does not auto-save the modified source. Quite different from default in VS. There is an option that you can set to change this behavior. I also noticed that the dependencies for libraries does not default to re-link a project using the library should the library change (I have not found the option to fix that behavior). These problems are IDE problems, not IVF (or GCC/G++ problems as is my situation).

The SOP (standard operating procedure) of most Linux projects is to import (copy sources) from elsewhere into the current workspace project folder. IOW you are using a stale copy of a source modified by someone else in a different project elsewhere. These too are IDE issues, and your (my)becoming familiar with the configuration of these tools.

Jim Dempsey

[dantzig]

Sorry guys, but I believe that you are out in left field. I am running the compiler from the command line in a terminal window. Old school, perhaps, but not subject to the errors you're describing. If I do this from the command line:

gfortran -o wtf wtf.f90
wtf

I get the correct answer. If I then do from the command line

ifort -o wtf wtf.f90
wtf

I get the wrong answers. Further, if I edit the file and insert a print statement, then recompile with ifort, the new statement is printed in the output, along with the wrong answers.

Jon

[mecej4]

I usually don't let my imagination run wild to the extent of conflating creating programs with procreation.

If you can reproduce the bug in a CLI environment (in a Console Window or whatever the thing is called on MACOS -- I have not used a Mac/NeXT in a decade), and show the command lines and compiler options, that would give us something more useful to work with than an imaginative program name alone.

[Steven_L_Intel1]

Which Xcode version are you using?

[dantzig]

Steve hit it. The problem was Xcode. I found the workaround using the compiler flag -use-asm that allows ifort 11.1 to work with Xcode 3.2.2. The following compilation produces the correct answer:

ifort -o wtf -use-asm wtf.f90

Thanks!

Jon