Bug 462821 – gcc-gfortran allocates incorrect amount of memory.

Bug 462821 - gcc-gfortran allocates incorrect amount of memory.

Summary:	gcc-gfortran allocates incorrect amount of memory.

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Enterprise Linux 5
Classification:	Red Hat
Component:	gcc (Show other bugs)
Sub Component:
Version:	5.2
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	rc
Target Release:	---
Assigned To:	Jakub Jelinek
QA Contact:	BaseOS QE
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2008-09-19 02:27 EDT by Wade Mealing
Modified:	2010-10-23 00:39 EDT (History)
CC List:	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
Add an attachment (proposed patch, testcase, etc.)

Groups: 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.