Description of problem: The test program exposes a problem with gcc-gfortran that Version-Release number of selected component (if applicable): gcc-gfortran-4.1.2-42.el5 How reproducible: Every time Steps to Reproduce: 1. Compile test program 2. Run Test program 3. observe output. Actual results: RHEL/Linux uses different memory for the same application compiled in gfortran between different platforms. Expected results: Gfortran programs to use the same memory. Additional info: Intels fortran compiler suffers from the same problem. It has a very similar bug on Linux where it reports back memory used incorrectly. Test programs and platform results to be attached.
Created attachment 317159 [details] Sample output 1
Created attachment 317160 [details] Sample output 2
I don't understand where do you think is a problem. LOC gives you an address of an object. Obviously the addresses of .bss or .data objects can differ between different architectures, they can differ even between different linking if any component such as libc, libgfortran etc. changed. Addresses of dynamically allocated objects (ALLOCATABLE e.g.) can be different even between different runs of the same program, even if no library or binary changed. And subtracting an address of a dynamically allocated object and .data/.bss object gives you a value that can of course differ between different runs. BTW, LOC(A(350)) is invalid, when the array has DIMENSION 1, you can't take address of 350's element.