[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-04-01 06:17:51 UTC --- BTW, from this experience, it would be great to have the frontend optimizations being protected by a switch (-f(no-)frontend-optimizations or similar) which can default to true at -O1 and higher. First, this would provide an easy workaround for this kind of bugs. Second, this would make sense in combination with LTO, where in principle one could compile in the first pass with -O0, and only at link time with -Ox (this makes sense from a compile time point of view). However, for this to generate good code, the first pass should be -O0 -ffrontend-optimizations, otherwise the middle end would have no chance.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #9 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-04-01 19:31:27 UTC --- Author: tkoenig Date: Fri Apr 1 19:31:23 2011 New Revision: 171849 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171849 Log: 2011-04-01 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/48352 * frontend-passes (cfe_register_funcs): Don't register functions if they appear as iterators in DO loops. 2011-04-01 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/48352 * gfortran.dg/function_optimize_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/function_optimize_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-04-01 19:32:35 UTC --- Fixed, closing.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-31 12:54:26 UTC --- The regression is caused by r171207.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-03-31 13:05:29 UTC --- (In reply to comment #3) The regression is caused by r171207. That's http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00630.html Author: tkoenig Date: Mon Mar 21 07:14:42 2011 New Revision: 171207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171207 Log: 2010-03-21 Thomas Koenig PR fortran/22572 [...]
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-03-31 13:25:27 UTC --- reduced: INTEGER, DIMENSION(:), POINTER :: a DO I=1,MIN(SIZE(a),SIZE(a)) ENDDO END
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-31 15:01:31 UTC --- I am a little suspicious of this: static int count_arglist; +/* Pointer to an array of gfc_expr ** we operate on, plus its size + and counter. */ + +static gfc_expr ***expr_array; +static int expr_size, expr_count; It could be getting walked on or optimized away by the optimizers. Is there another way to do this that is less indirect or relies less on static. Just seems too tricky. I do not have time to go further with this.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-03-31 18:31:22 UTC --- (In reply to comment #5) reduced: INTEGER, DIMENSION(:), POINTER :: a DO I=1,MIN(SIZE(a),SIZE(a)) ENDDO END Thanks, Joost. Slightly more reduced test case (from the point of stepping through the code): interface pure integer function f() end function f end interface DO I=1,min(f(),f()) ENDDO END Somehow, the insertion of the statement with the extra variable doesn't work for DO loops.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.30 20:43:03 Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-03-30 20:43:03 UTC --- Really strange. gdb shows Program received signal SIGSEGV, Segmentation fault. gfc_expr_walker (e=0x18, exprfn=0x597fc0 cfe_expr_0, data=0x0) at ../../trunk/gcc/fortran/frontend-passes.c:752 752 while (*e) (gdb) up #1 0x005984ec in gfc_code_walker (c=0x1452b30, codefn=0x597330 cfe_code, exprfn=0x597fc0 cfe_expr_0, data=0x0) at ../../trunk/gcc/fortran/frontend-passes.c:1050 1050 WALK_SUBEXPR ((*c)-ext.omp_clauses-chunk_size); (gdb) p (*c)-op $1 = EXEC_ASSIGN (gdb) p (*c)-ext.omp_clauses $2 = (gfc_omp_clauses *) 0x0 Why are we in the section dealing with OMP stuff when handling an EXEC_ASSIGN? We should not get there at all.
[Bug fortran/48352] [4.7 Regression] segfault in fortran/frontend-passes.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48352
Jerry DeLisle jvdelisle at gcc dot gnu.org changed:
What|Removed |Added
CC||jvdelisle at gcc dot
||gnu.org
--- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-03-31
04:56:02 UTC ---
This fixes it.
Index: gcc/fortran/frontend-passes.c
===
--- gcc/fortran/frontend-passes.c(revision 171769)
+++ gcc/fortran/frontend-passes.c(working copy)
@@ -334,6 +334,8 @@ cfe_code (gfc_code **c, int *walk_subtrees ATTRIBU
static void
optimize_namespace (gfc_namespace *ns)
{
+ if (!ns-code)
+return;
current_ns = ns;
Regression tested.
trim_optimize_2.f90 fails but I do not know if this is because the patterns are
changed or this patch is just disabling the optimizations.
Also moving the check down a little bit still works, as follows.
Index: gcc/fortran/frontend-passes.c
===
--- gcc/fortran/frontend-passes.c(revision 171769)
+++ gcc/fortran/frontend-passes.c(working copy)
@@ -334,11 +334,14 @@ cfe_code (gfc_code **c, int *walk_subtrees ATTRIBU
static void
optimize_namespace (gfc_namespace *ns)
{
-
current_ns = ns;
gfc_code_walker (ns-code, cfe_code, cfe_expr_0, NULL);
+
gfc_code_walker (ns-code, optimize_code, optimize_expr, NULL);
+
+ if (!ns-code)
+return;
for (ns = ns-contained; ns; ns = ns-sibling)
optimize_namespace (ns);
I think somewhere while walking the code, the code pointer is getting bashed or
for this test case, it really is null.
Hope this at least gives some hints.
