[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #25 from jakub at gcc dot gnu dot org 2007-09-25 10:26 --- Subject: Bug 27954 Author: jakub Date: Tue Sep 25 10:26:01 2007 New Revision: 128758 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128758 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/27954 * decl.c (gfc_free_data_all): New function to free all data structures after errors in DATA statements and declarations. (top_var_list): Use new function.(top_val_list): Use new function. (gfc_match_data_decl): Use new function. PR libgfortran/27954 * gfortran.dg/error_recovery_2.f90: New test. Added: branches/redhat/gcc-4_1-branch/gcc/testsuite/gfortran.dg/error_recovery_2.f90 Modified: branches/redhat/gcc-4_1-branch/gcc/fortran/ChangeLog branches/redhat/gcc-4_1-branch/gcc/fortran/decl.c branches/redhat/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2007-02-04 20:10 --- *** Bug 30701 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||imre dot bartfai at chello ||dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:47 --- Subject: Bug 27954 Author: jvdelisle Date: Fri Oct 27 20:47:28 2006 New Revision: 118084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118084 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR fortran/27954 * decl.c (gfc_free_data_all): New function to free all data structures after errors in DATA statements and declarations. (top_var_list): Use new function.(top_val_list): Use new function. (gfc_match_data_decl): Use new function. * misc.c (gfc_typename): Fixed incorrect function name in error text. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/misc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:55 --- Subject: Bug 27954 Author: jvdelisle Date: Fri Oct 27 20:54:54 2006 New Revision: 118086 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=118086 Log: 2006-10-27 Jerry DeLisle [EMAIL PROTECTED] PR libgfortran/27954 Fix type in changelog, pr number * gfortran.dg/error_recovery_2.f90: New test. Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2006-10-27 20:58 --- Fixed on 4.3 Only -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #16 from pault at gcc dot gnu dot org 2006-10-20 09:20 ---
The problem is specific to old-style initializers, as
program FOO
real :: x = 2.0 q
real z /2.0/ q
end program FOO
shows (comment out each declaration in turn!).
Grepping on the first error message leads us to decl.c(gfc_match_data_decl).
Proceeding to the Doxygen documentation, we find right away that there is
nothing in the loop over variables that would distinguish old-style data, so
this must happen in variable_decl.
eh voila!
01186 return match_old_style_init (name);
In this function, we find that the gfc_data, it produces, contains an
expression that points to the symtree for the variable. In ALL OTHER error
routes, this gfc_data is freed so that the hanging pointer to the symtree and
to the soon to be non-existent symbol is removed.
match_old_style_init returns SUCCESS and so has hung the gfc_data entry onto
gfc_current_ns-data where it remains until the compiler splutters its last on
trying to swallow it.
Once we figure that, we know right away that this fixes the problem:
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (révision 117879)
--- gcc/fortran/decl.c (copie de travail)
*** ok:
*** 2368,2373
--- 2368,2384
gfc_error (Syntax error in data declaration at %C);
m = MATCH_ERROR;
+ /* Check if there are any old fashioned data statements around.
+ If there are, they risk leaving dangling symtree references
+ and do nothing for us since an error has occurred. */
+ for (;gfc_current_ns-data;)
+ {
+ gfc_data *d;
+ d = gfc_current_ns-data-next;
+ gfc_free (gfc_current_ns-data);
+ gfc_current_ns-data =d;
+ }
+
cleanup:
gfc_free_array_spec (current_as);
current_as = NULL;
This is not checked for breakages or regtested but I believe that it is the
right solution.
It does not fix PR18923 but I think that something similar is at play and could
be investigated in the same way.
(Jerry, I am preparing to depart on a trip; I would be happy if you would
finish off the development of this patch because I cannot return to it for at
least a week.)
Regards
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:27 --- This does not fix it, but I think the idea is in the right direction. There are multiple error return paths like this that are not cleaning up enough. This explains why making variations on the test case gives several different errors and results. I will pursue to completion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2006-10-20 14:33 --- Correction: The patch in #16 fixes the case in #11. However I have several other variations on this that are taking a different error path. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #19 from pault at gcc dot gnu dot org 2006-10-20 14:35 --- Thank goodne for that - I thought that I was going batty! Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-10-20 16:25 --- To make you feel better. I have found the other spots. Those are fixed as well and regression tested AOK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:24 --- I believe this is a duplicate of PR18923. What I am finding is that under some error conditions, we end up with empty symbols. When gfc resolve is executed we are bumping into this arror because the sym-name is equal to '\0'. With this patch the call to gfc_get_default_type is avoided and we get a clean exit. This begs the question, should these empty symbols be left to begin with. This fixes both bugs. I have found another bug, playing with variations on the test case that gives a similar error in gfc_typename. Index: symbol.c === --- symbol.c(revision 117876) +++ symbol.c(working copy) @@ -223,6 +223,9 @@ gfc_set_default_type (gfc_symbol * sym, if (sym-ts.type != BT_UNKNOWN) gfc_internal_error (gfc_set_default_type(): symbol already has a type); + + if (*sym-name == '\0') +return FAILURE; ts = gfc_get_default_type (sym, ns); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:26 --- *** Bug 18923 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||Thomas dot Koenig at online ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-20 03:54 --- Another test case with similar error: program friend character*20 y, x 0 data y /'abcdef'/, x /'jbnhjk'/ o print *, basketcase end program friend $ gfc pr27954.f90 In file pr27954.f90:2 character*20 y, x 0 1 Error: Syntax error in data declaration at (1) In file pr27954.f90:3 data y /'abcdef'/, x /'jbnhjk'/ o 1 Error: Syntax error in DATA statement at (1) In file pr27954.f90:6 end program friend 1 Internal Error at (1): gfc_typespec(): Undefined type This actually is error in gfc_typename () The error message has a typo in it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #15 from pault at gcc dot gnu dot org 2006-10-20 04:50 --- Jerry, I got your message and will reply later - I have to run for the bus! I have been aware that there is a problem with empty symbols for some little while. Whilst on the way to the lab, I will contemplate how to diagnose it. I think they arise out of the commit_symbol mechanism but I am not entirely sure. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||paul dot richard dot thomas ||at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-09-11 01:34 --- Another example showing this is not specific to DATA statements, but is related to parsing the initilizer. program FOO character*20 Y /'Abcdef'/ garbage end program FOO $ gfc pr27954.f90 In file pr27954.f90:2 character*20 Y /'Abcdef'/ garbage 1 Error: Syntax error in data declaration at (1) In file pr27954.f90:3 end program FOO 1 Internal Error at (1): gfc_get_default_type(): Bad symbol Its interesting that the syntax error is caught, but the following END statement gets mangled. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-16 02:23:27 |2006-09-11 01:34:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-09-11 01:40 --- I can coax a segfault out of this: program FOO character*20 Y /'Abcdef'/ 0 print *, Y end program FOO $ gfc pr27954.f90 In file pr27954.f90:2 character*20 Y /'Abcdef'/ 0 1 Error: Syntax error in data declaration at (1) pr27954.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-06-16 02:23 --- Confirmed as the bug was reproduced by Steve. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-16 02:23:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-12 12:45 --- Well, the Internal Error at the end of the eror message doesn't look like the right thing to me: Internal Error at (1): gfc_get_default_type(): Bad symbol And this happens since GCC 4.0.0. I.e. GCC 4.0.x, 4.1.x, and mainline are affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-12 14:23 --- I don't see the internal error. laptop:kargl[205] cat r.f90 subroutine FOO character*20 X 0 data X /'A'/0 end subroutine FOO laptop:kargl[206] gfc -c r.f90 In file r.f90:3 character*20 X 0 1 Error: Syntax error in data declaration at (1) In file r.f90:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) In file r.f90:4 data X /'A'/0 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4) laptop:kargl[208] gfc -c r.f In file r.f:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) In file r.f:4 data X /'A'/0 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4) laptop:kargl[209] gfc --version GNU Fortran 95 (GCC) 4.2.0 20060610 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-12 15:32 --- Maybe it's target dependent? Are you using --enable-checking? I have % gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-threads --enable-checking --prefix=/somepath/gcc-4.2-20060612 --with-gmp=/somepath/GMP --with-mpfr=/somepath/MPFR Thread model: posix gcc version 4.2.0 20060612 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2006-06-12 23:04 --- Subject: Re: ICE on garbage in DATA statement On Mon, Jun 12, 2006 at 03:32:15PM -, reichelt at gcc dot gnu dot org wrote: - Comment #4 from reichelt at gcc dot gnu dot org 2006-06-12 15:32 --- Maybe it's target dependent? I'm guessing this is the case. Are you using --enable-checking? I had not checking on i386-*-freebsd and this morning I rebuilt with --enable-checking on amd64-*-freebsd. I do not see the Internal Compiler Error. troutmask:sgk[203] gfc4x -v Using built-in specs. Target: amd64-unknown-freebsd7.0 Configured with: ../gcc4x/configure --prefix=/home/sgk/work/4x --enable-languages=c,fortran --enable-checking Thread model: posix gcc version 4.2.0 20060612 (experimental) troutmask:sgk[204] gfc4x -c l.f90 In file l.f90:3 character*20 X 0 1 Error: Syntax error in data declaration at (1) In file l.f90:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) In file l.f90:4 data X /'A'/0 1 Error: Incompatible types in assignment at (1), CHARACTER(1) to REAL(4) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-06-12 23:26 --- I can reproduce the bug also on i686-pc-linux-gnu. Does freebsd vs. linux really matter that much here? Or could GMP or MPFR be the culprit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu 2006-06-13 00:35 --- Subject: Re: ICE on garbage in DATA statement On Mon, Jun 12, 2006 at 11:26:16PM -, reichelt at gcc dot gnu dot org wrote: I can reproduce the bug also on i686-pc-linux-gnu. Does freebsd vs. linux really matter that much here? Or could GMP or MPFR be the culprit? I doubt it is gmp or mpfr. There is nothing in the program that uses either library. Can you run the executable under valgrind? The difference may be in the memory allocators, which do differ between linux and freebsd. Yep. That's the problem. troutmask:sgk[211] setenv MALLOC_OPTIONS AJ troutmask:sgk[213] troutmask:sgk[213] gfc4x -c l.f90 In file l.f90:3 character*20 X 0 1 Error: Syntax error in data declaration at (1) In file l.f90:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) l.f90:0: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2006-06-13 00:56 --- Subject: Re: ICE on garbage in DATA statement On Mon, Jun 12, 2006 at 05:34:52PM -0700, Steve Kargl wrote: On Mon, Jun 12, 2006 at 11:26:16PM -, reichelt at gcc dot gnu dot org wrote: I can reproduce the bug also on i686-pc-linux-gnu. Does freebsd vs. linux really matter that much here? Or could GMP or MPFR be the culprit? I doubt it is gmp or mpfr. There is nothing in the program that uses either library. Can you run the executable under valgrind? The difference may be in the memory allocators, which do differ between linux and freebsd. Yep. That's the problem. troutmask:sgk[211] setenv MALLOC_OPTIONS AJ troutmask:sgk[213] troutmask:sgk[213] gfc4x -c l.f90 In file l.f90:3 character*20 X 0 1 Error: Syntax error in data declaration at (1) In file l.f90:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) l.f90:0: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Program received signal SIGBUS, Bus error. 0x004458c3 in gfc_resolve_expr (e=0x201520240) at ../../gcc4x/gcc/fortran/resolve.c:2793 2793 if (sym-attr.flavor == FL_PROCEDURE !sym-attr.function) (gdb) bt #0 0x004458c3 in gfc_resolve_expr (e=0x201520240) at ../../gcc4x/gcc/fortran/resolve.c:2793 #1 0x00447413 in resolve_data_variables (d=0x2014212c0) at ../../gcc4x/gcc/fortran/resolve.c:5867 #2 0x00447671 in resolve_types (ns=0x2014a2000) at ../../gcc4x/gcc/fortran/resolve.c:5896 #3 0x00449cbd in gfc_resolve (ns=0x2014a2000) at ../../gcc4x/gcc/fortran/resolve.c:6558 #4 0x0043f958 in gfc_parse_file () at ../../gcc4x/gcc/fortran/parse.c:3190 #5 0x0045e90e in gfc_be_parse_file (set_yydebug=Variable set_yydebug is not available. ) at ../../gcc4x/gcc/fortran/f95-lang.c:303 #6 0x0074595e in toplev_main (argc=Variable argc is not available. ) at ../../gcc4x/gcc/toplev.c:999 -- Steve -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #1 from kargl at gcc dot gnu dot org 2006-06-12 00:02 --- Okay, your bug report says gcc 4.0.0 and the reported against field says 4.2.0. Which is correct, because gfortran does the right thing with gcc 4.2.0. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
