[Bug fortran/54389] New: [F2003/F2008 difference] PURE functions and pointer dummy arguments

[Bug fortran/54389] New: [F2003/F2008 difference] PURE functions and pointer dummy arguments

[burnus at gcc dot gnu.org]

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

             Bug #: 54389
           Summary: [F2003/F2008 difference] PURE functions and pointer
                    dummy arguments
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: diagnostic, rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Broad up in the comp.lang.fortran "Function questions?" thread
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/r4PVbtaBnFM 

Ian Harvey remarks there that Fortran 2008 removed a restriction regarding
PURE. 


Fortran 2003 has:

"C1272   In a pure subprogram any designator with a base object that [...] is a
dummy argument of a pure function, is a dummy argument with INTENT (IN) of a
pure subroutine [...] shall not be used in the following contexts: [...]"


Fortran 2008 changed it to:

"C1283   In a pure subprogram any designator with a base object that [...] is a
dummy argument with the INTENT (IN) attribute [...] shall not be used [...]"


Note: Both standards (F2003:C1266, F2008:C1276) require that all *nonpointer*
dummy arguments to pure *functions* have the INTENT(IN) or VALUE attribute.

However, there is no such restriction for pointers. Hence, an INTENT(OUT) or
INTENT(INOUT) pointer is allowed - also for functions - and it may be used in
pointer assignments (both sides), variable definition contexts etc. - like in a
normal procedure. 


Currently, the following program is rejected with:
  Error: Variable 'ptr' can not appear in a variable definition context
         (assignment) at (1) in PURE procedure

(As a side remark: I wonder whether it should be made clearer that this applies
to a pure FUNCTION rather than to a pure SUBROUTINE. And the error message
feels a bit incomplete, maybe one should add the procedure name at the end.)


  PURE INTEGER FUNCTION foo (ptr)
    INTEGER, INTENT(INOUT), POINTER :: ptr
    ptr = ptr + 1
    foo = 1
  END FUNCTION foo

[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org
            Summary|[F2003/F2008 difference]    |[F2003/F2008 difference]
                   |PURE functions and pointer  |PURE functions and pointer
                   |dummy arguments             |dummy arguments /
                   |                            |DECL_PURE_P issue

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-08-28 08:39:54 UTC ---
Post script: I think one can argue that the F2008 change makes sense: If one
has specified INTENT(OUT)/INTENT(INOUT), it doesn't make sense to treat it as
INTENT(IN). Additionally, the pointer attribute of the actual and dummy
argument already ensures that certain alias issues do not occur.

(I looked at the Fortran 2003 corrigenda 1 to 5 and at the Fortran 2008
corrigendum 1 - and at some IR, but I couldn't find anything relevant there.)

I am not 100% sure whether it matches with DECL_PURE_P. It actually doesn't
seems so do so:
  DECL_PURE_P
    This predicate holds if the function can only read its arguments, but may
    also read global memory.

Hence, we need to be careful with it for declaring (implicitly) pure functions.

 * * * 

Side note: The following code is wrong due to IMPURE ELEMENTAL:

  if (sym->attr.pure || sym->attr.elemental)
    {
      if (sym->attr.function && !gfc_return_by_reference (sym))
        DECL_PURE_P (fndecl) = 1;

[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-08-28 18:18:15 UTC ---
Author: burnus
Date: Tue Aug 28 18:18:11 2012
New Revision: 190757

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190757
Log:
2012-08-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/54389
        * trans-decl.c (gfc_get_extern_function_decl,
        build_function_decl): Don't mark impure elemental
        functions as DECL_PURE_P and honour implicit_pure.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c

[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch

--- Comment #3 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-09-12 10:00:46 UTC ---
This revision causes CP2K to produce wrong results at -O1 and above. I don't
have a reduced testcase, other than compiling and building CP2K, but found this
by bisection.

[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-12 10:29:57 UTC ---
(In reply to comment #0)
> Ian Harvey remarks there that Fortran 2008 removed a restriction regarding
> PURE. 

Dick Hendrickson asked at j3's mailing list (on 2012-09-05) whether that was
intended; no reply so far.

[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-13 19:49:11 UTC ---
(In reply to comment #3)
> This revision causes CP2K to produce wrong results at -O1 and above.

That bug has been analysed and fixed, see PR 54556.


(In reply to comment #4)
> Dick Hendrickson asked at j3's mailing list (on 2012-09-05) whether that was
> intended; no reply so far.

Actually, Bob had answered; he reads the standard in the same way as Dick and
Ian (cf. comment 0).

[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-10-20
     Ever confirmed|0                           |1

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling the test in comment 0 still gives the error

     ptr = ptr + 1
    1
Error: Variable 'ptr' can not appear in a variable definition context
(assignment) at (1) in PURE procedure

at revision r229078 (trunk 6.0).

[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #6)
> Compiling the test in comment 0 still gives the error
> 
>      ptr = ptr + 1
>     1
> Error: Variable 'ptr' can not appear in a variable definition context
> (assignment) at (1) in PURE procedure
> 
> at revision r229078 (trunk 6.0).

That error looks correct to me.  NAG rejects the code as well for any INTENT.

To reconfirm: F2023 has

"C15104 In a pure subprogram any designator with a base object that [...]
is a pointer dummy argument of a pure function [...] shall not be used

(1) in a variable definition context"

There is no restriction on the INTENT of the pointer dummy.

See also Note 4, 2nd paragraph for reasoning supporting this.

Can we close this bug as fixed?