View previous topic :: View next topic |
Author |
Message |
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Sat Jul 18, 2020 2:48 pm Post subject: 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.
Code: | 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 |
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Sat Jul 18, 2020 4:10 pm Post subject: |
|
|
mecej4
Thank you for the feedback. I have made a note of this. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Sat Jul 18, 2020 5:00 pm Post subject: |
|
|
This has now been fixed for the next release of FTN95. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Sat Jul 18, 2020 6:53 pm Post subject: |
|
|
So that's a useful extension gone before anyone but Mecej4 even knew it was there ... |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Wed Jul 22, 2020 6:15 am Post subject: |
|
|
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. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Jul 22, 2020 7:44 am Post subject: |
|
|
You can have equivalences within a module. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Wed Jul 22, 2020 9:36 am Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Jul 22, 2020 12:16 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2390 Location: Yateley, Hants, UK
|
Posted: Wed Jul 22, 2020 1:29 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Wed Jul 22, 2020 2:32 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Wed Jul 22, 2020 5:36 pm Post subject: |
|
|
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.
Code: | 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
Code: | 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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Thu Jul 23, 2020 2:19 am Post subject: Re: |
|
|
mecej4 wrote: | 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. |
|
Back to top |
|
|
|