[Bug fortran/49436] New: Modifying actual arguments in subroutine not detected

[Bug fortran/49436] New: Modifying actual arguments in subroutine not detected

[tjf at rsc dot anu.edu.au]

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

           Summary: Modifying actual arguments in subroutine not detected
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: tjf@rsc.anu.edu.au
              Host: i686-pc-linux-gnu


Created attachment 24544
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24544
Nonconforming code that compiles happily

There's an aspect of the f95 standard that seems to not be enforced by
gfortran.

As I interpret it, the standard says that if an object passed as an actual
argument is also accessible in a subprogram through other means, then this can
only be modified through the corresponding dummy argument (12.4.1.6).

The attached code violates this by modifying a directly inside subroutine c,
rather than through the dummy argument n.  With gfortran 4.6.0 on
i686-pc-linux-gnu this nonconforming code compiles happily, even with -Wall
-std=f95 -pedantic.

When run, two 15s are printed despite the value 2 being passed as intent(in)
(clearly the argument is passed by reference).

[Bug fortran/49436] Modifying actual arguments in subroutine not detected

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #1 from janus at gcc dot gnu.org 2011-06-16 12:00:52 UTC ---
(In reply to comment #0)
> As I interpret it, the standard says that if an object passed as an actual
> argument is also accessible in a subprogram through other means, then this can
> only be modified through the corresponding dummy argument (12.4.1.6).

I guess you refer to this part:


(2) If the value of any part of the entity is affected through the dummy
argument, then at any time during the execution of the procedure, either before
or after the definition, it may be referenced only through that dummy argument
unless
(a) the dummy argument has the POINTER attribute,
(b) the part is all or part of a pointer subobject, or
(c) the dummy argument has the TARGET attribute, the dummy argument does not
have INTENT (IN), the dummy argument is a scalar object or an assumed-shape
array, and the actual argument is a target other than an array section with a
vector subscript.


And indeed I would interpret it in the same way as you do. However, the
question is whether the standard requires the *compiler* to enforce this
restriction, or if it is simply a restriction that the programmer is supposed
to follow.

Are you aware of any compiler which enforces this restriction?

[Bug fortran/49436] Modifying actual arguments in subroutine not detected

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-06-16 12:04:35 UTC ---
(In reply to comment #0)
> There's an aspect of the f95 standard that seems to not be enforced by
> gfortran.

The Fortran standard only requires that constraints ("C<number>" in the
standard) are checked by the compiler. Some other things might be checkable
(and compilers do diagnose some of those) - either at compile time or at run
time, but for a lot of code, it is practically impossible to diagnose the
invalidity.

Your program belongs to the latter:

call c(a)
[...]
subroutine c(n)
integer,intent(in)::n
a=15

This cannot be detected in general - and in specific cases only with
difficulty. I doubt that any Fortran compiler can detect this at compile time -
and I am not sure whether there is any which can do so at run time.

Assume, the variable "a" is in one file, the caller in another and the callee
in the third. In that case it should be clear that a compile-time diagnostic is
unfortunately not possible.

By the way, the result of your program depends on the compiler. Some might do a
copy-in of the argument, in that case "n" and "a" are disjunct. Or the compiler
might not do so - which gives the known result that modifying "a" also modifies
"n".


Thus, I think it is (unfortunately) a WONTFIX bug.

[Bug fortran/49436] Modifying actual arguments in subroutine not detected

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |kargl at gcc dot gnu.org
         Resolution|                            |WONTFIX

--- Comment #3 from kargl at gcc dot gnu.org 2011-06-16 16:34:29 UTC ---
See comments #1 and #2.  Closing as WONTFIX.