public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sgk at troutmask dot apl dot washington dot edu" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/19292] [meta-bug] g77 features lacking in gfortran Date: Sun, 08 Jan 2006 01:58:00 -0000 [thread overview] Message-ID: <20060108015814.19623.qmail@sourceware.org> (raw) In-Reply-To: <bug-19292-8513@http.gcc.gnu.org/bugzilla/> ------- 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
next prev parent reply other threads:[~2006-01-08 1:58 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-19292-8513@http.gcc.gnu.org/bugzilla/> 2005-11-12 23:29 ` fxcoudert at gcc dot gnu dot org 2006-01-07 20:30 ` malitzke at metronets dot com 2006-01-07 21:55 ` kargl at gcc dot gnu dot org 2006-01-07 22:17 ` sgk at troutmask dot apl dot washington dot edu 2006-01-08 0:33 ` malitzke at metronets dot com 2006-01-08 0:51 ` pinskia at gcc dot gnu dot org 2006-01-08 1:58 ` sgk at troutmask dot apl dot washington dot edu [this message] 2006-01-08 2:30 ` Tobias dot Schlueter at physik dot uni-muenchen dot de 2006-01-08 2:43 ` sgk at troutmask dot apl dot washington dot edu 2006-01-08 10:41 ` malitzke at metronets dot com 2006-01-08 13:18 ` tobi at gcc dot gnu dot org 2006-01-08 16:37 ` sgk at troutmask dot apl dot washington dot edu 2006-01-08 20:27 ` pault at gcc dot gnu dot org 2006-05-27 19:24 ` sgk at troutmask dot apl dot washington dot edu 2006-05-27 20:24 ` Thomas dot Koenig at online dot de 2006-05-27 20:28 ` sgk at troutmask dot apl dot washington dot edu 2006-07-03 12:14 ` franke dot daniel at gmail dot com 2006-07-03 12:58 ` fxcoudert at gcc dot gnu dot org 2006-07-03 16:41 ` jvdelisle at gcc dot gnu dot org 2006-07-03 17:17 ` sgk at troutmask dot apl dot washington dot edu 2006-07-26 12:07 ` fxcoudert at gcc dot gnu dot org 2006-10-02 9:41 ` fxcoudert at gcc dot gnu dot org 2006-12-17 18:21 ` pertusus at free dot fr 2006-12-18 21:39 ` pertusus at free dot fr 2007-08-14 23:22 ` fxcoudert at gcc dot gnu dot org 2007-08-16 12:10 ` fxcoudert at gcc dot gnu dot org 2005-01-06 14:39 [Bug fortran/19292] New: [metabug] " tobi at gcc dot gnu dot org 2005-01-20 10:47 ` [Bug fortran/19292] [meta-bug] " Thomas dot Koenig at online dot de 2005-01-22 22:33 ` pbrook at gcc dot gnu dot org 2005-01-23 0:25 ` dje at gcc dot gnu dot org 2005-01-23 22:38 ` pbrook at gcc dot gnu dot org 2005-01-29 15:39 ` pinskia at gcc dot gnu dot org 2005-02-19 12:59 ` wilson at gcc dot gnu dot org 2005-02-20 22:21 ` kargl at gcc dot gnu dot org 2005-02-22 13:07 ` pinskia at gcc dot gnu dot org 2005-02-24 14:32 ` rth at gcc dot gnu dot org 2005-03-11 14:17 ` pinskia at gcc dot gnu dot org 2005-03-13 19:10 ` tobi at gcc dot gnu dot org 2005-03-13 19:29 ` tobi at gcc dot gnu dot org 2005-03-14 20:17 ` tobi at gcc dot gnu dot org 2005-03-16 0:19 ` fengwang at gcc dot gnu dot org 2005-03-16 14:32 ` tobi at gcc dot gnu dot org 2005-03-17 2:14 ` pinskia at gcc dot gnu dot org 2005-03-22 22:17 ` fxcoudert at gcc dot gnu dot org 2005-03-22 23:19 ` tobi at gcc dot gnu dot org 2005-03-25 7:07 ` fxcoudert at gcc dot gnu dot org 2005-03-25 13:37 ` fxcoudert at gcc dot gnu dot org 2005-03-26 17:44 ` pinskia at gcc dot gnu dot org 2005-04-03 8:10 ` fxcoudert at gcc dot gnu dot org 2005-04-06 9:54 ` fxcoudert at gcc dot gnu dot org 2005-04-08 11:12 ` fxcoudert at gcc dot gnu dot org 2005-04-20 1:10 ` milan at cmm dot ki dot si 2005-04-20 1:15 ` pinskia at gcc dot gnu dot org 2005-04-23 16:11 ` pault at gcc dot gnu dot org 2005-04-23 16:14 ` pault at gcc dot gnu dot org 2005-04-23 16:15 ` pault at gcc dot gnu dot org 2005-04-23 16:18 ` pault at gcc dot gnu dot org 2005-04-24 14:01 ` tobi at gcc dot gnu dot org 2005-04-30 17:53 ` pinskia at gcc dot gnu dot org 2005-05-03 7:05 ` tkoenig at gcc dot gnu dot org 2005-05-03 19:47 ` tkoenig at gcc dot gnu dot org 2005-05-03 19:50 ` tkoenig at gcc dot gnu dot org 2005-05-03 19:52 ` tkoenig at gcc dot gnu dot org 2005-05-05 23:26 ` pinskia at gcc dot gnu dot org 2005-05-11 11:18 ` pinskia at gcc dot gnu dot org 2005-05-15 3:25 ` pinskia at gcc dot gnu dot org 2005-05-31 17:01 ` ebotcazou at gcc dot gnu dot org 2005-06-16 22:29 ` fxcoudert at gcc dot gnu dot org 2005-06-16 23:04 ` fxcoudert at gcc dot gnu dot org 2005-06-17 16:25 ` fxcoudert at gcc dot gnu dot org 2005-07-01 22:11 ` pinskia at gcc dot gnu dot org 2005-07-07 9:56 ` fengwang at gcc dot gnu dot org 2005-07-09 12:14 ` tobi at gcc dot gnu dot org 2005-07-12 4:25 ` pinskia at gcc dot gnu dot org 2005-07-12 4:26 ` pinskia at gcc dot gnu dot org 2005-07-12 4:26 ` pinskia at gcc dot gnu dot org 2005-07-14 15:23 ` pault at gcc dot gnu dot org 2005-07-16 20:54 ` pinskia at gcc dot gnu dot org 2005-07-19 8:48 ` fxcoudert at gcc dot gnu dot org 2005-07-19 21:45 ` steven at gcc dot gnu dot org 2005-08-02 10:52 ` fxcoudert at gcc dot gnu dot org 2005-08-06 13:35 ` pinskia at gcc dot gnu dot org 2005-08-31 12:52 ` fxcoudert at gcc dot gnu dot org 2005-09-08 18:51 ` rsandifo at gcc dot gnu dot org 2005-09-09 22:17 ` pinskia at gcc dot gnu dot org 2005-09-09 22:17 ` pinskia at gcc dot gnu dot org 2005-09-12 11:07 ` tobi at gcc dot gnu dot org 2005-09-16 8:57 ` fxcoudert at gcc dot gnu dot org 2005-09-18 19:53 ` tkoenig at gcc dot gnu dot org 2005-09-29 21:33 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20060108015814.19623.qmail@sourceware.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).