From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19659 invoked by alias); 8 Jan 2006 01:58:16 -0000 Received: (qmail 19624 invoked by alias); 8 Jan 2006 01:58:14 -0000 Date: Sun, 08 Jan 2006 01:58:00 -0000 Message-ID: <20060108015814.19623.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/19292] [meta-bug] g77 features lacking in gfortran In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "sgk at troutmask dot apl dot washington dot edu" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-01/txt/msg00697.txt.bz2 List-Id: ------- 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