--- Comment #23 from burnus at gcc dot gnu dot org 2007-10-31 15:11 ---
> > Alternative patch (bootstraps/regtests).
> I think it's better to go that way: apparently, care has been taken until now
> to keep module files alphanumeric, let's keep it that way.
> If your patch regetests fine
--- Comment #22 from burnus at gcc dot gnu dot org 2007-10-31 15:10 ---
Subject: Bug 33941
Author: burnus
Date: Wed Oct 31 15:10:12 2007
New Revision: 129801
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129801
Log:
2007-10-31 Tobias Burnus <[EMAIL PROTECTED]>
PR for
--- Comment #21 from fxcoudert at gcc dot gnu dot org 2007-10-31 14:04
---
(In reply to comment #20)
> Alternative patch (bootstraps/regtests).
I think it's better to go that way: apparently, care has been taken until now
to keep module files alphanumeric, let's keep it that way.
If y
--- Comment #20 from burnus at gcc dot gnu dot org 2007-10-31 13:35 ---
Alternative patch (bootstraps/regtests).
I'm not sure how soon I can submit it.
Index: gcc/fortran/module.c
===
--- gcc/fortran/module.c(Revis
--- Comment #19 from dominiq at lps dot ens dot fr 2007-10-31 11:11 ---
Minimal quick and dirty patch (including Tobias' one) that fixes the composite
relational operators:
--- /opt/gcc/_gcc-clean/gcc/fortran/module.c2007-10-28 21:01:20.0
+0100
+++ /opt/gcc/gcc-4.3-work/gcc/
--- Comment #18 from dominiq at lps dot ens dot fr 2007-10-30 23:25 ---
> (SIGN_* is a bit of a lousy naming, but I don't have any better idea)
what about GFC_* ? However I wonder about possible conflicts with user defined
operator. Is that so difficult to parse ==, /=, <=, and =>?
--
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-10-30 23:20
---
For other operators, ie .eqv., we output them as the simple EQV string (without
the dots). What about outputting the troublesome operators into simple
alphanumeric strings, like SIGN_EQ for ==, SIGN_NE for /=, SI
--- Comment #16 from dominiq at lps dot ens dot fr 2007-10-30 23:10 ---
If I replace <= by == or /=, the error becomes:
Fatal Error: Reading module foo at line 21 column 16: find_enum(): Enum not
found
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33941
--- Comment #15 from dominiq at lps dot ens dot fr 2007-10-30 23:07 ---
Sorry, but the Tobias' patch is not enough. With the full test I get now:
Fatal Error: Reading module m_common_attrs at line 120 column 55: Expected left
parenthesis
line 120 reads:
INTEGER ()) 0 '0')) (OP (LOGICA
--- Comment #14 from patchapp at dberlin dot org 2007-10-30 19:40 ---
Subject: Bug number PR33941
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01832.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #13 from dominiq at lps dot ens dot fr 2007-10-30 18:43 ---
> Well, the patch which exactly does in code what you said in words
> is the following:
Obviously, I would have forgotten "/"! Is not it a good candidate for the
"obvious" rule?
--
http://gcc.gnu.org/bugzilla/s
--- Comment #12 from burnus at gcc dot gnu dot org 2007-10-30 17:27 ---
(In reply to comment #11)
> The use of '<', '>', and '=' has been introduced in revision 126468. However
> looking at proc parse_atom in gcc/fortran/module.c, they do not seem to be in
> the recognized character set.
12 matches
Mail list logo
