[Bug fortran/39239] New: Reject SAVEd variables EQUIVALENCEd to a COMMON

[Bug fortran/39239] New: Reject SAVEd variables EQUIVALENCEd to a COMMON

[burnus at gcc dot gnu dot org]

The following program is presumably invalid (I have not checked the standard).
ifort and sunf95 reject it with:

warning #6755: A COMMON block data object may not have the SAVE attribute.

ERROR: Object "I2" has the SAVE attribute, so it must not be equivalenced to an
object in a common block.

Ad hoc I don't see why it is only a warning and not an error with ifort.

(g95, gfortran, NAG 95 accept it without warning.)


integer :: i1, i2
common /block/ i1
save i2
equivalence(i1,i2)
end


-- 
           Summary: Reject SAVEd variables EQUIVALENCEd to a COMMON
           Product: gcc
           Version: 4.4.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=39239

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2009-02-19 15:37 -------
I now asked at c.l.f but so far there was no direct pointer to the standard. 
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/695d799c2e81b1b3

I think (in line with the replies in c.l.f) that

"C517 (R501) The SAVE attribute shall not be specified for an object that is in
             a common block [...]"

plus some wording in the storage association part of the standard implies that
an object which is equivalent to a common object is also itself a common
object.

If I read Tim's reply correctly, ifort has only a warning since the SAVE does
not matter: COMMON block variables are always in the static memory ("SAVE"). 

Still, I would follow sunf95/openf95/pathf95 (which all seem to have a common
linage) and print an error and not a warning.


-- 


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

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2009-02-19 22:29 -------
Glan found the relevant part (see link above for more):

In 5.5.2.1: "Data objects associated with an entity in a common
             block are considered to be in that common block."

 * * *

BIND(C) in equivalence is wrong in general (see C576); there is currently a
warning printed, but the message is misleading:

module m
  integer :: i1, i2
  bind(C) :: i2
! common /block/ i1
  equivalence(i1,i2)
end module m

With COMMON, the warning (!) is the following; note that /BLOCK/ is not bind(C)
contrary to the message:

"Warning: Variable 'i1' in common block 'block' at (1) may not be a C
interoperable kind though common block 'block' is BIND(C)

Without COMMON, the warning (!) is also misleading:

"Warning: Variable 'i2' at (1) may not be a C interoperable kind but it is
bind(c)"

 * * *

Protected is already handled (cf. C584):
"Error: Either all or none of the objects in the EQUIVALENCE set at (1) shall
have the PROTECTED attribute"

 * * *

Volatile is not handled, though it [probably] should (cf. NOTE 5.22)
  integer :: i1, i2
  VOLATILE :: i2
  equivalence(i1,i2)
  end

 * * *

Asynchronous: Not yet supported in gfortran.


-- 


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

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[pault at gcc dot gnu dot org]

------- Comment #3 from pault at gcc dot gnu dot org  2009-03-08 16:11 -------
Confirmed

Paul


-- 


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

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[pault at gcc dot gnu dot org]

------- Comment #4 from pault at gcc dot gnu dot org  2009-03-14 09:56 -------
Helps to confirm it:-)


-- 

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         |2009-03-14 09:56:29
               date|                            |


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