[Bug fortran/43289] New: Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[Bug fortran/43289] New: Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[burnus at gcc dot gnu dot org]

Fortran 2003 (corrigendum 5, ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1815.pdf)
has now:

Subclause 12.6
Following constraint C1271, add the following new constraint:

   C1271a The designator of a variable with the VOLATILE attribute shall not
   appear in a pure subprogram.

"A designator is a name followed by zero or more component selectors, array
section selectors, array element selectors, and substring selectors."


My understanding is that thus the following program is invalid:

pure subroutine foo(a, c, d)
  integer, volatile, intent(inout) :: a, c ! OK
  integer, volatile :: b ! OK
  integer :: d
  b = 4 ! Invalid LHS as "b" is volatile
  d = b ! Invalid RHS
end subroutine


-- 
           Summary: Missed constraint C1271a: Referrencing VOLATILE variable
                    in PURE subprogram
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: accepts-invalid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2010-03-28 20:39 -------
(In reply to comment #0)

> My understanding is that thus the following program is invalid:
> 
> pure subroutine foo(a, c, d)
>   integer, volatile, intent(inout) :: a, c ! OK
>   integer, volatile :: b ! OK
>   integer :: d
>   b = 4 ! Invalid LHS as "b" is volatile
>   d = b ! Invalid RHS
> end subroutine
> 

I can see why the LHS should be invalid but why the RHS?

I have confirmed it since it is manifestly 50% a bug!  Note that ifort 11.1
does not detect it.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-28 20:39:01
               date|                            |


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

[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[dfranke at gcc dot gnu dot org]

------- Comment #2 from dfranke at gcc dot gnu dot org  2010-05-07 18:06 -------
*** Bug 39289 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

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

--- Comment #3 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-12-11 09:04:58 UTC ---
Also invalid:

module foo
  implicit none
  real, volatile:: vol
contains
  pure subroutine bar(a)
    real, intent(out) :: a
    a = vol
  end subroutine bar
end module foo

F2008 has

"C1282 A designator of a variable with the VOLATILE attribute shall not
appear in a pure subprogram."

[Bug fortran/43289] Missed constraint C1271a: Referrencing VOLATILE variable in PURE subprogram

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-11 17:17:18 UTC ---
Created attachment 26047
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26047
Draft patch w/ test case

Patch TODO: Handle implicit pure, cf. PR 51502.

The error location is not ideal, but finding the expression locus requires
adding this check at every place where sym->referenced.