[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

["malitzke at metronets dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #11 from malitzke at metronets dot com  2006-01-08 00:33 -------
Last things first: The code posted in 25705 is copyrighted 1994 and published
in Computer Physics Communications; hence just modification by a third party
could be legally questionable. The two academics (one in computer Science)
conceivably were cogniscent of the f90 standard. Anyhow, standards sould be
quoted in context, I have the Sep 2002 working draft (only abrogating f77, f90,
and f95, per Annex B) which per Para 8.1.1.2 matches the quotation in comment
10. However, the 105 label precedes the first executable statement. Now, line
18 of 8.1 reads as follows:

Any of these constructs may be named. If a construct is named, the name shall
be the first lexical token of the first statement of the construct and the last
lexical token of the construct. In fixed source form, the name preceding the
construct shall be placed after character position 6. 

Therefore, the 105 GOTO address clearly is not inside the construct, because it
 immediately follows the ELSE and precedes character position 6 of the
construct proper; and 8.1.1.2 does not apply.

If label 105 would not precede the block, but be inside, then error message,
pertaining to the inside of the block would be proper.

Also, if commercial compilers would have a clear basis to issue an error
message, they probably would do so and get off the hook.

As I am clearly no the author the the code, I have no real position to defend.
As my post 25705 makes clear legalistic arguments should be avoided. I also
coded a parallel C program and used f2c on the code fragment posted. In both
cases gcc-4.1.0 emitted object code without complaint. In this respect C and
fortran are both block structured languages without nesting of subroutines.
Therefore, if gcc-4.1.0 can handle it for C a parallel construct should do it
for fortran.


-- 


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