From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5739 invoked by alias); 8 Jan 2006 00:33:31 -0000 Received: (qmail 5709 invoked by uid 48); 8 Jan 2006 00:33:29 -0000 Date: Sun, 08 Jan 2006 00:33:00 -0000 Message-ID: <20060108003329.5708.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: "malitzke at metronets dot com" 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/msg00692.txt.bz2 List-Id: ------- 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