[Bug fortran/51638] gfortran optimization breaks a single variable used as both input and output for subroutine call

["kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org 2011-12-20 17:44:56 UTC ---
(In reply to comment #1)
> (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.

Actually, the same variable is used as the actual argument in the
call to the subroutine, and the actual argument becomes associated
with two different dummy argument.

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

Huh?  It is not invalid to have an entity appear as multiple
actual arguments in an argument list.

> (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.)

You even state that it is valid!  The problem is that the OP
modifies on of the dummy arguments.  This is clearly discussed
in 

12.4.1.7  Restrictions on entities associated with dummy
          arguments

While an entity is associated with a dummy argument, the
following restrictions hold:
  (1) ... Action that affects the value of the entity or
      any subobject of it shall be taken only through the
      dummy argument unless ...

      (unless stuff involves things with POINTER or
       TARGET attributes, which OP doesn't have)

Further down in Note 12.29

If there is a partial or complete overlap between the actual
arguments associated with two different dummy arguments of
the same procedure and the dummy arguments have neither the
POINTER nor TARGET attribute, the overlapped portions shall
not be defined, redefined, or become unde- fined during the
execution of the procedure. For example, in

CALL SUB (A(1:5), A(3:9))

A(3:5) shall not be defined, redefined, or become undefined
through the first dummy argument because it is part of the
argument associated with the second dummy argument and shall
not be defined, redefined, or become undefined through the
second dummy argument because it is part of the argument
associated with the first dummy argument. A(1:2)remains
definable through the first dummy argument and A(6:9)
remains definable through the second dummy argument.