differences in 32 and 64bit compilation

I am looking for pointers in debugging 64bit vs 32bit programs.
I have a C/F77 graphics app using X Windows. I am able to successfully compile and execute the 32 bit version. However, using the x86_64 version on the same machine gives a segmentation fault.

I am dealing with the graphics library of a larger simulation program. In all, the graphics library has around 300 source files — and about 4 lines of comments for the whole thing (yeah, it’s a DoE/DoD app). I am able to figure out where the segmentation fault occurs (a pointer mysteriously becomes null). Unfortunately, I can’t determine why.

My question is: What difference is there in the compilation of 32bit vs 64bit codes? Can you shed some insight on why one version might execute properly but the other can’t execute?

PS Mat, thanks for your help on the common block problem. BTW this is another part of the same app.

Hi kstephens,

Sounds like a fun program! Most likely you do have a 64-bit portability problem since these issues mostly occur when mixing C and Fortran. Of course it could be something else, but well start with portability.

The main difference between 32 and 64-bit programming is that the size of pointers and C ‘long’ data types have gone from 4 to 8 bytes. When calling C routines from Fortran and visa versa, you need to make sure that the sizes of you data types match up. So if your calling a C function which expects a ‘long’ and your passing in an “INTEGER”, then you’ve got problems since you need to be passing an "INTEGER8". Also, if your returning a ‘long’ from a C function, make sure the Fortran caller has declared the function as 'INTEGER8’.

As for your pointer magically turning null, if the pointer is local it will be stored on the program stack. Mismatched data types can cause variables to be over written, and thus become corrupt.

Hope this helps,
Mat

This may also be a bug with the 6.0.5 64 bit compiler. I spent a couple of days working with a PG technical support person by email trying to sort out why I was getting memory corrupted in a 64 bit compilation version of my code and not with the 32 bit version. Again, like you and several other posters in this forum - the problem arose in a mixed C and Fortran environment. I don’t have much C code - mostly an interface to the C library for date, time and random number functions that were not provided in older fortran compilers - and the technical support person and I went over it in detail without identifying any porting issues. It got to the point where he needed a register by register comparison between the 32 and 64 bit versions to try to identify the issue. Personally, I don’t have the time to spend on it.

However, to add something useful, I have just replaced the C in my code with the equivalent f90 library functions it and I STILLl get corruption of data occuring in the 64 bit version which does not exist in the 32 bit version. However, some calls to the so-called 3F functions which may use the C library intrinsically still remain in the code - getenv and mclock among others for example. However, if this is the source of the problem then it is definitely a 64 bit compiler bug since presumably the libraries and their interface are correct.

As an additional note, producing 64 bit output compiled with -g instead of -O gives a direct memory fault error message instead of my code giving an error mesage because some piece of stored data has mysteriously changed.

At the present time - I would deem the 64 bit PGI fortran compilers simply unusable for my application. Luckily, everything woks fine in 32 bit by just adding the -tp k8-32 flag and the -m32 flag for the small amount of C code I have. I wonder how many folks have run into problems with the 64 bit compilers and simply ignore it since it works in 32 bit?

Cheers,

David

P.S. Actually I’m curious - do you have to adjust the variables passed to the 3F category functions provided by PGI for the differences between 32 and 64 bits? I would have thought this would have been handled by PGI since they provide that functionality at the fortran level rather than with an inter language interface.