Bug 462821 - gcc-gfortran allocates incorrect amount of memory.
gcc-gfortran allocates incorrect amount of memory.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jakub Jelinek
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-19 02:27 EDT by Wade Mealing
Modified: 2010-10-23 00:39 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-02 03:08:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Sample output 1 (3.09 KB, application/octet-stream)
2008-09-19 02:39 EDT, Wade Mealing
no flags Details
Sample output 2 (3.45 KB, application/octet-stream)
2008-09-19 02:39 EDT, Wade Mealing
no flags Details

  None (edit)
Description Wade Mealing 2008-09-19 02:27:07 EDT
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.
Comment 2 Wade Mealing 2008-09-19 02:39:26 EDT
Created attachment 317159 [details]
Sample output 1
Comment 3 Wade Mealing 2008-09-19 02:39:59 EDT
Created attachment 317160 [details]
Sample output 2
Comment 4 Jakub Jelinek 2008-09-19 06:47:02 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.