Bug 1622238

Summary:	GFortran mis-handles EQUIVALENCES in multiple ways
Product:	Red Hat Developer Toolset	Reporter:	Jeff Law <law>
Component:	gcc	Assignee:	Marek Polacek <mpolacek>
Status:	CLOSED ERRATA	QA Contact:	Michael Petlan <mpetlan>
Severity:	unspecified	Docs Contact:	Vladimír Slávik <vslavik>
Priority:	unspecified
Version:	DTS 7.1 RHEL 7	CC:	bgollahe, jakub, kanderso, law, mcermak, mnewsome, mpetlan, mpolacek, ohudlick
Target Milestone:	alpha
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-08-30 17:24:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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