That's not my obvious thought! :-) That kind of "this can't be
real" behavior makes me think that maybe you have some sort of
linking issue -- are there several objects getting linked together?
Can you do a "make clean" and rebuild and does that help?
There is a step where a bunch of object files are put into an
archive for linking, but I always remove all of the object files and
archive file before doing a rebuild.
Another "obvious" thought to me is that perhapss you have a buffer
overflow error in a stack or heap variable.
Similar to what Eddie posted, I tried compiling an executable with
all checking turned on ( -C ) and when I do this and compile the code,
the executable runs to completion without any problems.
If you leave the write statement out, I forget, what happens? Your
program crashes? Where does it crash? What call is being made?
The program crashes with a:
forrtl: severe (174): SIGSEGV, segmentation fault occurred
And in gdb it tells me where:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000014d7fffff
0x00000001001fc8cd in for__get_s ()
(gdb) backtrace
#0 0x00000001001fc8cd in for__get_s ()
#1 0x000000010021337b in for_read_seq_fmt ()
#2 0x0000000100148b27 in getprm () at getprm.f:108
#3 0x0000000100146851 in field () at field.f:57
#4 0x000000010019f6fb in mechanic () at mechanic.f:54
#5 0x0000000100001467 in analyze () at analyze.f:50
#6 0x00000001000013e4 in main ()
The last two function calls originate from the Intel libraries
itself.
The same code builds and run as a 32-bit executable. Everything I
try to do to see if the problem is originating in the code causes the
problem to go away. But I don't want to say it's a compiler bug until
I show more conclusively that something stupid in the code is causing
this.
The same code also compiles and runs fine (as a 32-bit or 64-bit
executable) with gfortran and the Portland Compilers on Mac OS X.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Scitech mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
