Bug 1622238 - GFortran mis-handles EQUIVALENCES in multiple ways
Summary: GFortran mis-handles EQUIVALENCES in multiple ways
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Developer Toolset
Classification: Red Hat
Component: gcc
Version: DTS 7.1 RHEL 7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: alpha
: 8.0
Assignee: Marek Polacek
QA Contact: Michael Petlan
Vladimír Slávik
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-24 20:45 UTC by Jeff Law
Modified: 2018-08-30 17:24 UTC (History)
9 users (show)

Fixed In Version: devtoolset-7-gcc-7.3.1-5.13.el7
Doc Type: Bug Fix
Doc Text:
Previously, the GNU Fortran Compiler did not handle "EQUIVALENCE" statements that involved variables with the "AUTOMATIC" attribute. Support for handling these legacy constructs has been added, and they are now processed correctly.
Clone Of:
Environment:
Last Closed: 2018-08-30 17:24:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:2604 0 None None None 2018-08-30 17:24:14 UTC

Description Jeff Law 2018-08-24 20:45:16 UTC
Description of problem:
GFortran erroneously issues an error for EQUIVALENCES involving AUTOMATIC variables.  More generally testing for invalid attributes in an EQUIVALENCE needs to be done after the entire equivalence set is visible.

Additionally, for an EQUIVALENCE with AUTOMATIC variables, the compiler must continue to place those objects onto the stack, even if -fno-automatic.

Version-Release number of selected component (if applicable):


How reproducible:
> This is the test code we have:
>
> program recurse
> call cleanstack(42, 42)
> call recursive(42,0)
> call cleanstack(42, 42)
> call recursive(0,5)
> call cleanstack(42, 42)
> call recursive(0,5)
> end
>
> subroutine recursive(setup, count)
> integer*4 setup
> integer*4 count
> integer*4 setupcopy
> integer*4 countcopy
> integer*4 something
> automatic countcopy,something
> equivalence (countcopy, something)
> countcopy = count
>
> if (setup .gt. 0) setupcopy = setup
> print *, " > setup = ", setupcopy, " count = ", countcopy
> if (count .gt. 0) call recursive(setupcopy - 1, count - 1)
> print *, " < setup = ", setupcopy, " count = ", countcopy
> end
>
> subroutine cleanstack(dummy1, dummy2)
> integer*4 dummy1
> integer*4 dummy2
> integer*4 dummy3
> integer*4 dummy4
>
> dummy3 = dummy1
> dummy4 = dummy2
>
> print *, " = clean ", dummy1, " ", dummy2
> end
>
> The expected output would be
>
> = clean 42 42
>> setup = 42 count = 0
> < setup = 42 count = 0
> = clean 42 42
>> setup = 42 count = 5
>> setup = 41 count = 4
>> setup = 40 count = 3
>> setup = 39 count = 2
>> setup = 38 count = 1
>> setup = 37 count = 0
> < setup = 37 count = 0
> < setup = 37 count = 1
> < setup = 37 count = 2
> < setup = 37 count = 3
> < setup = 37 count = 4
> < setup = 37 count = 5
> = clean 42 42
>> setup = 37 count = 5
>> setup = 36 count = 4
>> setup = 35 count = 3
>> setup = 34 count = 2
>> setup = 33 count = 1
>> setup = 32 count = 0
> < setup = 32 count = 0
> < setup = 32 count = 1
> < setup = 32 count = 2
> < setup = 32 count = 3
> < setup = 32 count = 4
> < setup = 32 count = 5

Compile with -fno-automatic -frecursive

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Michael Petlan 2018-08-26 19:11:59 UTC
Is it the following?

$ scl enable devtoolset-7 -- gfortran -frecursive -fno-automatic -fdec-static -o test test.f90 
f951: Warning: Flag ‘-fno-automatic’ overwrites ‘-frecursive’
test.f90:17:22:
 equivalence (countcopy, something)
                      1
Error: EQUIVALENCE attribute conflicts with AUTOMATIC attribute in ‘countcopy’ at (1)

$ rpmquery devtoolset-7-gcc-gfortran
devtoolset-7-gcc-gfortran-7.3.1-5.10.el7.x86_64

Comment 2 Jakub Jelinek 2018-08-26 22:03:27 UTC
I see e.g. in fortran-08-007r2.pdf in 5.7.1.1:
"An equivalence-object shall not be a designator with a base object that is a dummy argument, a pointer, an allocatable variable, a derived-type object that has an allocatable ultimate component, an object of a nonsequence derived type, an object of a derived type that has a pointer at any level of
component selection, an automatic object, a function name, an entry name, a result name, a variable with the BIND attribute, a variable in a common block that has the BIND attribute, or a named constant."

Are the automatic variables not automatic objects in Fortran terms?

Comment 3 Jeff Law 2018-08-26 22:18:18 UTC
Mpetlan -- you have to use one or more of the legacy fortran options.  I don't recall which one offhand.

Jakub -- Certainly allowed in legacy codes.  I even found it explicitly allowed in various docs when I was doing research.

Ultimately Bloomberg needs it, so we have to do something here.  We already tried "don't do that" with them.  They were actually receptive to that until they dug deeper into their code and realized how much would have to change.

Comment 4 Jakub Jelinek 2018-08-26 23:18:11 UTC
After further reading, it seems automatic object as Fortran term is roughly variable length types, something where array bounds or other type parameters aren't initialization expressions (approx. constant expressions).
Then there is the DEC -fdec-static AUTOMATIC extension, I guess if the DEC derived implementations don't complain about conflicts between that attribute and equivalence, it might be ok.

Comment 6 Marek Polacek 2018-08-27 11:54:56 UTC
I think the options should be -std=extra-legacy -fdec-static -frecursive -fno-automatic

Comment 7 Michael Petlan 2018-08-29 21:05:16 UTC
VERIFIED for devtoolset-7-gcc-7.3.1-5.13.el{6,7}.

Comment 12 errata-xmlrpc 2018-08-30 17:24:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:2604


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