------- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2006-01-08 01:58 -------
Subject: Re: [meta-bug] g77 features lacking in gfortran
On Sun, Jan 08, 2006 at 12:33:29AM -0000, malitzke at metronets dot com wrote:
>
> 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.
So, contact the original authors! Posting the copryrighted code to
a mailing list is also questionable.
> Anyhow, standards should 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.
There are no named constructs in the code posted! The 105 in is a
*statement label*. A named construct in fixed form would be
c234567
n = 2
AAA: if (n == 1) then
n = 100
else if (n == 2) then AAA
n = 200
else AAA
n = 0
end if AAA
print *, n
end
> If label 105 would not precede the block, but be inside, then error message,
> pertaining to the inside of the block would be proper.
It is in a block. If we remove the unneeded lines, you have
506 IF(IX.EQ.0. AND. IY.EQ.1) THEN
A IF(IBACK3.EQ.0) THEN
AB IF(MGO.EQ.0) THEN
ABD N=4
AB ELSEIF(MGO.EQ.1) THEN
ABE IF(IBACK3.EQ.1) THEN
ABEF GO TO 105 ! rmg questionable goto
ABE ELSE
ABEG N=4
ABE ENDIF
AB ELSE
ABD GO TO 108
AB ENDIF
A ELSE
AC 105 IRHO=NU
AC RETURN
A ENDIF
A 108 MEMR=IRHO
ENDIF
Everything marked with an A is in the constituent block of the
outermost IF...ENDIF. Everything marked with the AB is in the
constituent block of the IF(IBACK3.EQ.0) THEN ... ELSE. Everything
marked with AC is in the constituent block of the ELSE ... ENDIF
that corresponds the IF(IBACK3.EQ.0) THEN. The "GO TO 105" is
transferring control into the AC block, which is prohibited!
> Also, if commercial compilers would have a clear basis to issue an error
> message, they probably would do so and get off the hook.
The wording in 8.1.1.2 is such that a compiler is not required by
the standard to issue an error here. The words are "Transfer of
control to the interior of a block from outside the block is
prohibited." The "is" provides wiggle room for a vendor. If the
"is" were "shall be", then an error message would be required.
> 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.
We're trying to write a Fortran 95 conforming compiler. We can't
avoid legalistic arguments. I'm sorry if this view offends you.
> 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.
C and Fortran are two different languages with two different standards.
f2c is at best a Fortran 77 compiler. The behavior you want may be
permitted by Fortran 77, but I would need to study the Fortran 77
standard before I make any judgement.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
