Compiler does not object to illegal Equivalence

The following code is illegal (see the comments in the code for the relevant section of the Fortran 95 standard), but FTN95 (Versions 5.5 as well as 8.64) raises no objections.

Module pelem_m
   Real pelem(400)
End Module

Subroutine hyd2d
   Use PELEM_m
   Real phi2d(100, 4)
   Equivalence (phi2d, pelem)   ! Illegal equiv. to Use-associated variable
                               ! Fortran 95, Sec. 5.5.1, penultimate Constraint
! 'The name of an equivalence-object shall not be a name made accessible by use
! association.'
   print *,shape(phi2d)
! REMOVED: code that does stuff with PHI2D
   Return
End Subroutine

mecej4

Thank you for the feedback. I have made a note of this.

This has now been fixed for the next release of FTN95.

So that's a useful extension gone before anyone but Mecej4 even knew it was there ...

Not sure anyone knew ? I think I've done this before.

Does this mean we can't have equivalence in a module, or only restricts between variables where 1 is in module and the other isn't ?

If so, I will have to go searching for use of equivalence.

You can have equivalences within a module.

I suppose that what I meant to ask was 'Did it work?' If it did work, then perhaps making it stop working was a case for /ISO. If John C has used it before, then changing the compiler to default to the strict case breaks his code.

Eddie

Eddie

I assumed that a) it would not work b) it's not a good way to program and c) no one would intentionally do it.

But I could review this, given evidence to the contrary.

Hi Paul,

Mecej4 said that it contravened the Standard, not that it didn't work. If it didn't work, then rejecting it makes sense. If it does work in FTN95 then the prohibition in the Standard is either (a) because people on the Committee can't get it to work with their product, or (b) because they hate Fortran as it was and are determined to make it something else. I'm inclined to believe both.

If you think that X is bad programming practice, then you need to stop working on Fortran, the whole of which probably constitutes bad practice to purists!

I may write a note on EQUIVALENCE and some of its uses.

Eddie

Eddie

As a result of your prompting, I have looked at this again.

I see now, as I did when I first looked at this, that the original intention was to trap this as a bug. It just wasn't quite coded correctly. A test and an error report were already in place.

I can see that an equivalence would work in this simple program but, off hand, I don't know if this kind of usage is generally safe.

It seems very unlikely to me that this fix will break existing code (famous last words).

mecej4

Do you have any thoughts on this?

John C: EQUIVALENCE was used in old codes, and compilers continue to support it even though it is now marked 'obsolescent' along with COMMON. What is not allowed by the standard is declaring EQUIVALENCE of a module variable in a declaration placed outside the module.

FTN95 simply failed to catch the error in the particular code that I stumbled upon. Here is another short code that appears very similar, but for this example FTN95 does issue an error message and that message is direct and clear.

module mymod
integer ij(10)
end module

program myprog
use mymod
integer pq(5,2)
equivalence (pq,ij)
!
call addi(pq,10)
print *,ij
end program

The compiler says

0008) equivalence (pq,ij)
*** Module variable IJ should not be equivalenced outside of its module
    1 ERROR  [<MYPROG> FTN95 v8.64.0]
*** Compilation failed

If there is a case where the forbidden use of EQUIVALENCE provides an otherwise unobtainable solution, we could welcome its support as an extension. I have yet to see one.

In this example, I started with an old Fortran IV/ Fortran 77 code, and attempted to consolidate prolific repetitions of lengthy COMMON blocks into shared declarations placed inside modules. I did not notice the conflict that would be produced by moving COMMON variables into modules and leaving the EQUIVALENCEs outside until I used another compiler than FTN95.

Modules help reduce data exposure to parts of code where that data should not be touched. EQUIVALENCE goes in the opposite direction. Therefore, mixing modules and EQUIVALENCE is a short cut to a mess if there are no restricting rules, either imposed by the standard or self-imposed, to prevent the mess.

Quoted from mecej4 Modules help reduce data exposure to parts of code where that data should not be touched. EQUIVALENCE goes in the opposite direction. Therefore, mixing modules and EQUIVALENCE is a short cut to a mess if there are no restricting rules, either imposed by the standard or self-imposed, to prevent the mess.

Lately I have seen a lot of comments about use of extensions in pre F90 codes, with some compilers (eg gFortran) now identifying 'F77 wrapper' approaches as errors. Some even suggest all non-standard legacy approaches should be made illegal. I disagree, but this approach will probably succeed.

However some of the claims about COMMON appear more like spin. Like MODULES, COMMON also restricts the scope of variables to the routines in which they are declared. Combining COMMON with INCLUDE is a preferred approach and has much of the functionality of modules, except for their extra public/private feature. Use of EQUIVALENCE in COMMON is based on matching the memory address of different type or rank of arrays/variables. We are told we are not smart enough to understand memory addresses, but are free to use POINTERS, which I think is a much riskier coding approach.

Given the importance of COMMON for early FORTRAN, marking it as 'obsolescent' looks like Committee madness to many who used earlier versions of Fortran.