--- Comment #15 from janus at gcc dot gnu dot org 2010-03-04 13:58 ---
Fixed with r157226. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from janus at gcc dot gnu dot org 2010-03-04 13:42 ---
Subject: Bug 43244
Author: janus
Date: Thu Mar 4 13:42:06 2010
New Revision: 157226
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157226
Log:
2010-03-04 Janus Weil
PR fortran/43244
* dec
--- Comment #13 from burnus at gcc dot gnu dot org 2010-03-04 12:40 ---
(In reply to comment #12)
> (In reply to comment #11)
> > I think it dates back to punch cards;
> Yes, I've seen those. However, being born too late, I never had the chance to
> use them :)
I also saw them in some s
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-04 12:06 ---
(In reply to comment #11)
> I think it dates back to punch cards;
Yes, I've seen those. However, being born too late, I never had the chance to
use them :)
> > I wouldn't expect anyone to use F03 FINAL statements i
--- Comment #11 from burnus at gcc dot gnu dot org 2010-03-04 11:22 ---
(In reply to comment #10)
> To me the code in comment #8 looks completely insane and unreadable, but if
> some crazy standards document says it's legal, then so be it :)
I think it dates back to punch cards; there i
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-04 10:35 ---
(In reply to comment #9)
> From: F2003, "3.3.2 Fixed source form": "Except in a character context, blanks
> are insignificant and may be used freely throughout the program."
I guess this is what triggered the famous
--- Comment #9 from burnus at gcc dot gnu dot org 2010-03-04 10:16 ---
From: F2003, "3.3.2 Fixed source form": "Except in a character context, blanks
are insignificant and may be used freely throughout the program."
One possibility is simply to return MATCH_NO for fixed form code if one
--- Comment #8 from burnus at gcc dot gnu dot org 2010-03-04 10:12 ---
(In reply to comment #6)
> Free or Fixed form is irrelevant. Fixed form may allow things like F I N AL
> but it still must have :: (or : whitespace :) to match. (Also, the invalid
> looking array qualifier in that
--- Comment #7 from janus at gcc dot gnu dot org 2010-03-04 09:17 ---
(In reply to comment #6)
> Without looking at the code yet, the matcher must see a space or double colon
> after the word FINAL before matching it. If it sees anything else, its a
> MATCH_NO not a MATCH_ERROR. If thi
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-03-04 02:34
---
Without looking at the code yet, the matcher must see a space or double colon
after the word FINAL before matching it. If it sees anything else, its a
MATCH_NO not a MATCH_ERROR. If this is being done then the s
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-03 15:40 ---
Quick fix for free form:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 157195)
+++ gcc/fortran/decl.c (working copy)
@@ -7810,6 +7810,
--- Comment #4 from burnus at gcc dot gnu dot org 2010-03-03 15:32 ---
Regarding the error message: The problem is the lazy evaluation of error
messages. If one sets a breakpoint at "gfc_error" one finds:
gfc_error (gmsgid=0xd25bd0 "Syntax error in %s statement at %C")
gfc_error (gmsgid
--- Comment #3 from burnus at gcc dot gnu dot org 2010-03-03 12:59 ---
(In reply to comment #0)
> We should at least make sure the FINAL keyword is separated by spaces
> when parsing stuff like this.
Be careful with this! In free format that's OK but fixed format has some
strange way of
13 matches
Mail list logo
