http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-20
17:20:46 UTC ---
(In reply to comment #0)
> the attached program provides 2 subroutines which do not run correctly if the
> program is compiled with the optimization option (-O).
I can reproduce it with
-O -m32
on x86-64-linux. It works with -O0 or with -O2 or higher. And it is independent
of the usual suspects, i.e. -fno-frontend-optimize and -mfpmath=sse do not
change the result.
I have not yet understood why it causes problems.
* * *
> The key point is that the same variable is used as 2 different dummy
> variables (input and output) in the calling sequence.
I think that's actually not the key point. While it is invalid (in the general
case) to pass twice the same argument, it does not seem to cause the problem.
(Passing the same argument multiple times is valid if one does not modify it;
also pointer and target attribute enable some valid use. However, your usage is
clearly invalid.)
The problem of passing the argument multiple times can be removed by changing
the code to:
call iei4ei( (in4), in4)
call iei8ei( (in8), in8)
(Note the "(...)".) However, the issue is unaffected by this change.
In terms of code validity, there are two other issues:
a) Wrong objects in EQUIVALENCE:
C591 (R566) If an equivalence-object is default integer, default real, double
precision real, default complex, default logical, or of numeric sequence type,
all of the objects in the equivalence set shall be of these types and kinds.
C594 (R566) If an equivalence-object is of an intrinsic type but is not default
integer, default real, double precision real, default complex, default logical,
or default character, all of the objects in the equivalence set shall be of the
same type with the same kind type parameter value.
b) Passing an INTEGER(kind=4) to an INTEGER(kind=1) is invalid.
Nevertheless, one should try to find out what goes wrong.
