[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #32 from tobi at gcc dot gnu dot org 2007-02-15 16:22 --- Fixed. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #31 from tobi at gcc dot gnu dot org 2007-02-15 16:20 --- Subject: Bug 30478 Author: tobi Date: Thu Feb 15 16:20:46 2007 New Revision: 122002 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122002 Log: PR fortran/30478 fortran/ * decl.c (create_enum_history, gfc_free_enum_history): Formatting fixes. (add_init_expr_to_sym): Remove ENUM-specific code-path. (variable_decl): Likewise. Formatting fix. (match_attr_spec): Remove ENUM-specific codepath. (gfc_match_enum): Fix typo in error message. (enumerator_decl): New. (gfc_match_enumerator_def): Strip down to code necessary for ENUMs, use enumerator_decl. testsuite/ * gfortran.dg/enum_4.f90: Update expected error message. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/enum_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #30 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-12 01:21 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-12 > 01:15 --- > Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) > >> --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 >> --- >> (In reply to comment #6) >>> Fortran is not release-critical and this bug appears to be purely within the >>> Fortran front end. >> Should I commit the patch for the next release candidate once the branch is >> unfrozen? Personally, I don't believe this a sufficiently important bug >> (being >> an ICE on weird invalid code designed deliberately to break the compiler), >> but >> if you don't want this regression in the release, I'll happily commit it in >> time for the next release candidate. > > Mark always says that if it's not c++ ;) > > Since it's a regression, I believe it's your call. The test could > be xfail'd if you decide the benefits aren't worth the risk. User-visibility of the bug is probably zero, so I don't think this is important enough :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-12 01:15 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) > --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- > (In reply to comment #6) > > Fortran is not release-critical and this bug appears to be purely within the > > Fortran front end. > > Should I commit the patch for the next release candidate once the branch is > unfrozen? Personally, I don't believe this a sufficiently important bug > (being > an ICE on weird invalid code designed deliberately to break the compiler), but > if you don't want this regression in the release, I'll happily commit it in > time for the next release candidate. Mark always says that if it's not c++ ;) Since it's a regression, I believe it's your call. The test could be xfail'd if you decide the benefits aren't worth the risk. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #28 from mark at codesourcery dot com 2007-02-12 01:11 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) tobi at gcc dot gnu dot org wrote: > --- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- > (In reply to comment #6) >> Fortran is not release-critical and this bug appears to be purely within the >> Fortran front end. > > Should I commit the patch for the next release candidate once the branch is > unfrozen? Personally, I don't believe this a sufficiently important bug > (being > an ICE on weird invalid code designed deliberately to break the compiler), but > if you don't want this regression in the release, I'll happily commit it in > time for the next release candidate. No, please leave any non-critical issues until after 4.1.2 is released. Then, when the 4.1 branch is reopened, you may check in the the patch for a possible future 4.1.3 release. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #27 from tobi at gcc dot gnu dot org 2007-02-12 01:03 --- (In reply to comment #6) > Fortran is not release-critical and this bug appears to be purely within the > Fortran front end. Should I commit the patch for the next release candidate once the branch is unfrozen? Personally, I don't believe this a sufficiently important bug (being an ICE on weird invalid code designed deliberately to break the compiler), but if you don't want this regression in the release, I'll happily commit it in time for the next release candidate. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC|Tobias dot Schlueter at | |physik dot uni-muenchen dot | |de | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #26 from tobi at gcc dot gnu dot org 2007-02-12 00:51 --- Subject: Bug 30478 Author: tobi Date: Mon Feb 12 00:51:43 2007 New Revision: 121837 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121837 Log: 2007-02-10 Tobias Schlueter <[EMAIL PROTECTED]> PR fortran/30478 fortran/ * decl.c (create_enum_history, gfc_free_enum_history): Formatting fixes. (add_init_expr_to_sym): Remove ENUM-specific code-path. (variable_decl): Likewise. Formatting fix. (match_attr_spec): Remove ENUM-specific codepath. (gfc_match_enum): Fix typo in error message. (enumerator_decl): New. (gfc_match_enumerator_def): Strip down to code necessary for ENUMs, use enumerator_decl. testsuite/ * gfortran.dg/enum_4.f90: Update expected error message. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/decl.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/enum_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #25 from tobi at gcc dot gnu dot org 2007-02-11 22:36 --- Subject: Bug 30478 Author: tobi Date: Sun Feb 11 22:35:56 2007 New Revision: 121830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121830 Log: 2007-02-11 Tobias Schlueter <[EMAIL PROTECTED]> PR fortran/30478 fortran/ * decl.c (add_init_expr_to_sym): Remove ENUM specific code. (variable_decl): Likewise. Rewrap comment. (match_attr_spec): Remove ENUM specific code. (gfc_match_enum): Fix typo in error message. (enumerator_decl): New function. (gfc_match_enumerator_def): Use enumerator_decl instead of variable_decl. Adapt code accordingly. testsuite/ * gfortran.dg/enum_4.f90: Update error message checks. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/enum_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #24 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-11 14:46 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) > 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-02/msg00933.html Works for me: http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00430.html Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #23 from patchapp at dberlin dot org 2007-02-10 20:25 --- Subject: Bug number PR30478 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-02/msg00933.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #22 from fxcoudert at gcc dot gnu dot org 2007-02-10 16:20 --- (In reply to comment #21) > Here's a much cleaner patch, which makes us give slightly worse error messages > than before. Thanks for taking care of this, Tobias. I'm not sure I think the second patch is "cleaner", what does it do better? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #21 from tobi at gcc dot gnu dot org 2007-02-10 02:50 ---
Here's a much cleaner patch, which makes us give slightly worse error messages
than before. I'll submit this to the list tomorrow when I'm done testing.
2007-02-10 Tobias Schlüter <[EMAIL PROTECTED]>
PR fortran/30478
fortran/
* decl.c (gfc_match_enum): Fix typo in error message.
* parse.c (match): Remove stray semicolon from macro definition.
(decode_statement): Don't allow data declarations in ENUMs or
ENUMERATOR definitions outside.
testsuite/
* gfortran.dg/enum_2.f90: Update regexps for error messages.
Index: gcc/testsuite/gfortran.dg/enum_2.f90
===
--- gcc/testsuite/gfortran.dg/enum_2.f90(revision 121787)
+++ gcc/testsuite/gfortran.dg/enum_2.f90(working copy)
@@ -5,9 +5,9 @@ program main
implicit none
enum, bind (c)
enumerator :: red, black
-integer :: x ! { dg-error "Unexpected data declaration" }
+integer :: x ! { dg-error "Unclassifiable statement" }
enumerator blue = 1 ! { dg-error "Syntax error in ENUMERATOR definition"
}
end enum
- enumerator :: sun ! { dg-error "ENUM" }
+ enumerator :: sun ! { dg-error "Unclassifiable statement" }
end program main
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 121787)
+++ gcc/fortran/decl.c (working copy)
@@ -4081,7 +4081,7 @@ gfc_match_enum (void)
return m;
if (gfc_notify_std (GFC_STD_F2003,
- "New in Fortran 2003: ENUM AND ENUMERATOR at %C")
+ "New in Fortran 2003: ENUM and ENUMERATOR at %C")
== FAILURE)
return MATCH_ERROR;
Index: gcc/fortran/parse.c
===
--- gcc/fortran/parse.c (revision 121787)
+++ gcc/fortran/parse.c (working copy)
@@ -84,7 +84,7 @@ match_word (const char *str, match (*sub
return st; \
else \
undo_new_statement (); \
-} while (0);
+} while (0)
static gfc_statement
decode_statement (void)
@@ -131,8 +131,10 @@ decode_statement (void)
match (NULL, gfc_match_pointer_assignment, ST_POINTER_ASSIGNMENT);
match (NULL, gfc_match_st_function, ST_STATEMENT_FUNCTION);
- match (NULL, gfc_match_data_decl, ST_DATA_DECL);
- match (NULL, gfc_match_enumerator_def, ST_ENUMERATOR);
+ if (gfc_current_state () != COMP_ENUM)
+match (NULL, gfc_match_data_decl, ST_DATA_DECL);
+ else
+match (NULL, gfc_match_enumerator_def, ST_ENUMERATOR);
/* Try to match a subroutine statement, which has the same optional
prefixes that functions can have. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #20 from tobi at gcc dot gnu dot org 2007-02-10 02:18 --- Forgot the ChangeLog: 2007-02-10 Tobias Schlüter <[EMAIL PROTECTED]> PR fortran/30478 * decl.c (variabl_decl): Add argument for case where we are compiling an ENUM declaration. (gfc_match_data_decl, gfc_match_enumerator_def: Update calls accordingly. It may be cleaner to create a stripped down sibling of variable_decl for use with ENUMERATORs, this would also make clearer which extensions we actually want to allow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #19 from tobi at gcc dot gnu dot org 2007-02-10 02:11 ---
This patch (the diff is against 4.1) fixes it on linux-i686 under valgrind.
I'm currently giving it the full testsuite exercise.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 121787)
+++ gcc/fortran/decl.c (working copy)
@@ -1037,7 +1037,7 @@ gfc_match_null (gfc_expr ** result)
symbol table or the current interface. */
static match
-variable_decl (int elem)
+variable_decl (int elem, bool enumerator)
{
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_expr *initializer, *char_len;
@@ -1293,7 +1293,7 @@ variable_decl (int elem)
initializer, the initialization value of the previous enumerator
(stored in last_initializer) is incremented by 1 and is used to
initialize the current enumerator. */
- if (gfc_current_state () == COMP_ENUM)
+ if (enumerator)
{
if (initializer == NULL)
initializer = gfc_enum_initializer (last_initializer, old_locus);
@@ -2317,7 +2317,7 @@ ok:
elem = 1;
for (;;)
{
- m = variable_decl (elem++);
+ m = variable_decl (elem++, false);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
@@ -4081,7 +4081,7 @@ gfc_match_enum (void)
return m;
if (gfc_notify_std (GFC_STD_F2003,
- "New in Fortran 2003: ENUM AND ENUMERATOR at %C")
+ "New in Fortran 2003: ENUM and ENUMERATOR at %C")
== FAILURE)
return MATCH_ERROR;
@@ -4123,7 +4123,7 @@ gfc_match_enumerator_def (void)
elem = 1;
for (;;)
{
- m = variable_decl (elem++);
+ m = variable_decl (elem++, true);
if (m == MATCH_ERROR)
goto cleanup;
if (m == MATCH_NO)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #18 from tobi at gcc dot gnu dot org 2007-02-09 14:53 ---
(In reply to comment #17)
> > Thank you, but I think MacIntel is officially unsupported with 4.1.
>
> Do you have a pointer to this decision? TIA
It's not listed as primary nor secondary platform in the release criteria,
neither for 4.1 nor for 4.2, and it's a primary platform for 4.3. Check
http://gcc.gnu.org/gcc-4.{1,2,3}/criteria.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #17 from dominiq at lps dot ens dot fr 2007-02-09 12:14 --- > Thank you, but I think MacIntel is officially unsupported with 4.1. Do you have a pointer to this decision? TIA -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #16 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-09 04:10 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: > --- Comment #15 from dominiq at lps dot ens dot fr 2007-02-08 22:25 > --- > I think there is definitively a problem with the as provided on MacIntel. If > you are interested > I can dig my archives, I think I have some trace of the problem. > Unfortunately > I have only > a limited access to a MacIntel machine. Thank you, but I think MacIntel is officially unsupported with 4.1. Tant pis. I'll use the Linux box to further investigate the problem there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #15 from dominiq at lps dot ens dot fr 2007-02-08 22:25 --- I think there is definitively a problem with the as provided on MacIntel. If you are interested I can dig my archives, I think I have some trace of the problem. Unfortunately I have only a limited access to a MacIntel machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-08 22:10 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: > --- Comment #13 from dominiq at lps dot ens dot fr 2007-02-08 22:06 > --- >> The build fails with errors of the following kind: >> /var/tmp//ccFScp77.s:3049:indirect jmp without `*' > > Sound familiar, aren't you speaking of MacIntel? I have done some testing on > MacIntel with > a prebuild gfortran and I remember having some problems with as. > > I did not build gcc 4.1 recently on PPC 10.4.8, but I have build 4.2 without > problem with as > > Apple Computer, Inc. version cctools-622.5.obj~13, GNU assembler version 1.38 Yes MacIntel, sorry, I should have said that. 4.2 is indeed fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #13 from dominiq at lps dot ens dot fr 2007-02-08 22:06 --- > The build fails with errors of the following kind: > /var/tmp//ccFScp77.s:3049:indirect jmp without `*' Sound familiar, aren't you speaking of MacIntel? I have done some testing on MacIntel with a prebuild gfortran and I remember having some problems with as. I did not build gcc 4.1 recently on PPC 10.4.8, but I have build 4.2 without problem with as Apple Computer, Inc. version cctools-622.5.obj~13, GNU assembler version 1.38 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-02-08 21:49 --- Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error) dominiq at lps dot ens dot fr wrote: > --- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 21:25 > --- >> I forgot that OS X is not supported by gcc 4.1 > > What do you mean? I have built gcc 4.1 on both OSX 10.3 an 10.4 several time. > > The build fails with errors of the following kind: /var/tmp//ccFScp77.s:3049:indirect jmp without `*' This is with $ as -version Apple Computer, Inc. version cctools-622.3.obj~2, GNU assembler version 1.38 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 21:25 --- > I forgot that OS X is not supported by gcc 4.1 What do you mean? I have built gcc 4.1 on both OSX 10.3 an 10.4 several time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #10 from tobi at gcc dot gnu dot org 2007-02-08 19:00 --- I forgot that OS X is not supported by gcc 4.1, and got my memory refreshed only after it was 3/4 of the build. I've now started a build on a Linux machine, but I will probably not have time to attend this bug before tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #9 from tobi at gcc dot gnu dot org 2007-02-08 00:44 --- I reviewed the patch which introduced ENUM support, will take a look at this tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-02-07 22:31 --- Reduced testcase: enum, bind (c) integer :: x enumerator blue end enum end It fails under valgrind for both i686-linux and x86_64-linux: ==5651== Invalid read of size 4 ==5651==at 0x9DBD13: __gmpz_add_ui (in /utmp/coudert/gfortran/irun/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951) ==5651==by 0x403EC2: gfc_enum_initializer (arith.c:2422) ==5651==by 0x4135A0: variable_decl (decl.c:1366) ==5651==by 0x413886: gfc_match_enumerator_def (decl.c:4497) ==5651==by 0x43F792: match_word (parse.c:63) ==5651==by 0x43FD59: decode_statement (parse.c:133) ==5651==by 0x4407AA: next_statement (parse.c:499) ==5651==by 0x441955: parse_spec (parse.c:1645) ==5651==by 0x442DB5: parse_progunit (parse.c:2886) ==5651==by 0x44304F: gfc_parse_file (parse.c:3224) ==5651==by 0x4613ED: gfc_be_parse_file (f95-lang.c:307) ==5651==by 0x652942: toplev_main (toplev.c:1021) ==5651== Address 0x4AA00C4 is 100 bytes inside a block of size 160 free'd ==5651==at 0x4905A18: free (vg_replace_malloc.c:233) ==5651==by 0x458644: gfc_free_symbol (symbol.c:2005) ==5651==by 0x458A1C: gfc_undo_symbols (symbol.c:2326) ==5651==by 0x43F743: reject_statement (parse.c:1323) ==5651==by 0x441950: parse_spec (parse.c:1669) ==5651==by 0x442DB5: parse_progunit (parse.c:2886) ==5651==by 0x44304F: gfc_parse_file (parse.c:3224) ==5651==by 0x4613ED: gfc_be_parse_file (f95-lang.c:307) ==5651==by 0x652942: toplev_main (toplev.c:1021) ==5651==by 0x3FF241C4BA: (below main) (in /lib64/tls/libc-2.3.4.so) Adding Tobias to the CC list, as I think he was the one who wrote the ENUMERATOR support. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||Tobias dot Schlueter at ||physik dot uni-muenchen dot ||de Last reconfirmed|2007-02-05 22:23:02 |2007-02-07 22:31:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-02-05 22:23 --- It's not target specific as it is also seen on i686-pc-linux-gnu with mainline, when compiling enum_2.f90 under valgrind: ==6149== Invalid read of size 4 ==6149==at 0x86522E3: __gmpz_add_ui (in /home/fxcoudert/svn/debug/irun/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951) ==6149== Address 0x1BA8B6B0 is 56 bytes inside a block of size 84 free'd ==6149==at 0x1B90044F: free (vg_replace_malloc.c:235) ==6149==by 0x80A0BA7: gfc_free_symbol (symbol.c:2005) ==6149== ==6149== Invalid read of size 4 ==6149==at 0x8652305: __gmpz_add_ui (in /home/fxcoudert/svn/debug/irun/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951) ==6149== Address 0x1BA8B6B4 is 60 bytes inside a block of size 84 free'd ==6149==at 0x1B90044F: free (vg_replace_malloc.c:235) ==6149==by 0x80A0BA7: gfc_free_symbol (symbol.c:2005) ==6149== ==6149== Invalid read of size 4 ==6149==at 0x804B387: gfc_enum_initializer (arith.c:2423) ==6149== Address 0x1BA8B6A0 is 40 bytes inside a block of size 84 free'd ==6149==at 0x1B90044F: free (vg_replace_malloc.c:235) ==6149==by 0x80A0BA7: gfc_free_symbol (symbol.c:2005) ==6149== ==6149== Invalid read of size 4 ==6149==at 0x804B38A: gfc_enum_initializer (arith.c:2423) ==6149== Address 0x1BA8B69C is 36 bytes inside a block of size 84 free'd ==6149==at 0x1B90044F: free (vg_replace_malloc.c:235) ==6149==by 0x80A0BA7: gfc_free_symbol (symbol.c:2005) It doesn't happen for other testcases I tried. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|hppa2.0w-hp-hpux11.11 | GCC host triplet|hppa2.0w-hp-hpux11.11 | GCC target triplet|hppa2.0w-hp-hpux11.11 | Known to fail||4.3.0 4.2.0 4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-02-05 22:23:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-02-04 22:48 --- Fortran is not release-critical and this bug appears to be purely within the Fortran front end. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #5 from danglin at gcc dot gnu dot org 2007-02-03 02:02 --- This is the only regression present in 4.1.2 RC1 on hppa*-*-hpux11* that I'm aware of. It's caused by using data for an object that has been freed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #4 from danglin at gcc dot gnu dot org 2007-01-30 23:25 --- This a regression from 4.1.1. See: http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg01032.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #3 from danglin at gcc dot gnu dot org 2007-01-30 23:15 ---
It appears that the object pointed to by last_initializer is free'd
by gfc_free_expr. This causes the change in value in
initializer->value.integer[0]._mp_d:
(gdb) p &initializer->value.integer[0]._mp_d
$16 = (mp_limb_t **) 0x400817e0
(gdb) watch *0x400817e0
Hardware watchpoint 3: *1074272224
(gdb) c
Continuing.
In file /mnt/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/enum_2.f90:8
integer :: x ! { dg-error "Unexpected data declaration" }
1
Error: Unexpected data declaration statement at (1)
Hardware watchpoint 3: *1074272224
Old value = 1074134928
New value = 0
0x7af697b4 in memset () from /usr/lib/libc.2
(gdb) bt
#0 0x7af697b4 in memset () from /usr/lib/libc.2
#1 0x0004c7ec in free_expr0 (e=0x400817a8) at ../../gcc/gcc/fortran/expr.c:217
#2 0x0004c988 in gfc_free_expr (e=0x400817a8)
at ../../gcc/gcc/fortran/expr.c:230
#3 0x0008b394 in gfc_free_symbol (sym=0x40081700)
at ../../gcc/gcc/fortran/symbol.c:1859
#4 0x0008b7dc in gfc_undo_symbols () at ../../gcc/gcc/fortran/symbol.c:2175
#5 0x00070c1c in reject_statement () at ../../gcc/gcc/fortran/parse.c:1075
#6 0x00072d1c in parse_spec (st=ST_END_ENUM)
at ../../gcc/gcc/fortran/parse.c:1402
#7 0x000742d0 in parse_progunit (st=1074272216)
at ../../gcc/gcc/fortran/parse.c:2325
#8 0x00074748 in gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:2621
#9 0x00095ec4 in gfc_be_parse_file (set_yydebug=1074272216)
at ../../gcc/gcc/fortran/f95-lang.c:289
#10 0x0018aa2c in toplev_main (argc=1074013248, argv=0x40042c40)
at ../../gcc/gcc/toplev.c:991
#11 0x000bf66c in main (argc=1074272216, argv=0x0) at ../../gcc/gcc/main.c:35
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-01-16
01:47 ---
Subject: Re: FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
> --- Comment #1 from kargl at gcc dot gnu dot org 2007-01-16 00:54 ---
> \> 0x003e75d8 in __gmpz_add_ui ()
> > (gdb) bt
> > #0 0x003e75d8 in __gmpz_add_ui ()
> > #1 0x0003402c in gfc_enum_initializer (last_initializer=0x400817a8, where=
> > {nextc = 0x0, lb = 0x0}) at ../../gcc/gcc/fortran/arith.c:2475
>
> Is your source up to date? arith.c contains 2447 lines of code.
Yes.
# svn diff arith.c
# wc arith.c
2493 6785 59118 arith.c
The call is here:
if (last_initializer != NULL)
{
mpz_add_ui (result->value.integer, last_initializer->value.integer, 1);
Note, that this is 4.1.2.
> > Dump of assembler code from 0x3e75c8 to 0x3e75e8:
> > 0x003e75c8 <__gmpz_add_ui+104>: ldw -70(sp),r3
> > 0x003e75cc <__gmpz_add_ui+108>: bv r0(rp)
> > 0x003e75d0 <__gmpz_add_ui+112>: ldw,mb -80(sp),r7
> > 0x003e75d4 <__gmpz_add_ui+116>: cmpib,>,n 0,r4,0x3e76d4 <__gmpz_add_ui+372>
> > 0x003e75d8 <__gmpz_add_ui+120>: ldw 0(r25),ret0
> > 0x003e75dc <__gmpz_add_ui+124>: add,l r5,ret0,ret0
> > 0x003e75e0 <__gmpz_add_ui+128>: cmpb,>>= ret0,r5,0x3e769c
> > <__gmpz_add_ui+316>
> > 0x003e75e4 <__gmpz_add_ui+132>: stw ret0,0(r22)
> >
>
> This suggests that you have a broken GMP, which isn't a gfortran problem.
We have for gmpz_add_ui in gmp.h:
#define mpz_add_ui __gmpz_add_ui
__GMP_DECLSPEC void mpz_add_ui __GMP_PROTO ((mpz_ptr, mpz_srcptr, unsigned long
int));
typedef __mpz_struct *mpz_ptr;
typedef __gmp_const __mpz_struct *mpz_srcptr;
Looking at the code in __gmpz_add_ui, it would appear that there is a
problem with the _mp_d field in the struct (i.e., null value). As this
has to be setup before the call and the call is from gfortran, it's not
clear that this is a GMP problem.
I started a new build so I can't debug this further until it completes.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #1 from kargl at gcc dot gnu dot org 2007-01-16 00:54 ---
\> 0x003e75d8 in __gmpz_add_ui ()
> (gdb) bt
> #0 0x003e75d8 in __gmpz_add_ui ()
> #1 0x0003402c in gfc_enum_initializer (last_initializer=0x400817a8, where=
> {nextc = 0x0, lb = 0x0}) at ../../gcc/gcc/fortran/arith.c:2475
Is your source up to date? arith.c contains 2447 lines of code.
> Dump of assembler code from 0x3e75c8 to 0x3e75e8:
> 0x003e75c8 <__gmpz_add_ui+104>: ldw -70(sp),r3
> 0x003e75cc <__gmpz_add_ui+108>: bv r0(rp)
> 0x003e75d0 <__gmpz_add_ui+112>: ldw,mb -80(sp),r7
> 0x003e75d4 <__gmpz_add_ui+116>: cmpib,>,n 0,r4,0x3e76d4 <__gmpz_add_ui+372>
> 0x003e75d8 <__gmpz_add_ui+120>: ldw 0(r25),ret0
> 0x003e75dc <__gmpz_add_ui+124>: add,l r5,ret0,ret0
> 0x003e75e0 <__gmpz_add_ui+128>: cmpb,>>= ret0,r5,0x3e769c <__gmpz_add_ui+316>
> 0x003e75e4 <__gmpz_add_ui+132>: stw ret0,0(r22)
>
This suggests that you have a broken GMP, which isn't a gfortran problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
