[Bug libgomp/84086] [8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug libgomp/84086] [8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Mon Jan 29 15:22:55 2018
New Revision: 257152

URL: https://gcc.gnu.org/viewcvs?rev=257152=gcc=rev
Log:
2018-01-29  Richard Biener  

PR tree-optimization/84086
* tree-ssanames.c: Include cfgloop.h and tree-scalar-evolution.h.
(flush_ssaname_freelist): When SSA names were released reset
the SCEV hash table.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssanames.c

[Bug libgomp/84086] [8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086

--- Comment #3 from Richard Biener  ---
Released by

#0  release_ssa_name_fn (fn=0x76a5f160, var=)
at /space/rguenther/src/svn/early-lto-debug/gcc/tree-ssanames.c:536
#1  0x013735fe in release_ssa_name (name=)
at /space/rguenther/src/svn/early-lto-debug/gcc/tree-ssanames.h:141
#2  0x01376b5c in release_defs (stmt=)
at /space/rguenther/src/svn/early-lto-debug/gcc/tree-ssanames.c:826
#3  0x013f6081 in adjust_simduid_builtins (htab=0x0)
at /space/rguenther/src/svn/early-lto-debug/gcc/tree-vectorizer.c:237
#4  0x013f7a49 in vectorize_loops ()
at /space/rguenther/src/svn/early-lto-debug/gcc/tree-vectorizer.c:839

but that doesn't clear the SCEV cache.  [I still think maintaining this
cache over pass boundaries is a ticking bomb...  we eventually should add
a verifier that walks the hashtable looking for released SSA names - but
that's not the only issue with the cache obviously!]

So here we're coming via

1416  if (!simple_iv (loop, loop_containing_stmt (stmt), lhs, iv, true))
1417return false;

of said stmt and get at the initial SCEV via the cache which was built when
the stmt was still _14 = _21;

So a slightly more generic fix than putting a scev_reset into the vectorizer
would be

Index: gcc/tree-ssanames.c
===
--- gcc/tree-ssanames.c (revision 257139)
+++ gcc/tree-ssanames.c (working copy)
@@ -29,6 +29,8 @@ along with GCC; see the file COPYING3.
 #include "stor-layout.h"
 #include "tree-into-ssa.h"
 #include "tree-ssa.h"
+#include "cfgloop.h"
+#include "tree-scalar-evolution.h"

 /* Rewriting a function into SSA form can create a huge number of SSA_NAMEs,
many of which may be thrown away shortly after their creation if jumps
@@ -241,6 +243,9 @@ verify_ssaname_freelists (struct functio
 void
 flush_ssaname_freelist (void)
 {
+  /* If there were any SSA names released reset the SCEV cache.  */
+  if (! vec_safe_is_empty (FREE_SSANAMES_QUEUE (cfun)))
+scev_reset_htab ();
   vec_safe_splice (FREE_SSANAMES (cfun), FREE_SSANAMES_QUEUE (cfun));
   vec_safe_truncate (FREE_SSANAMES_QUEUE (cfun), 0);
 }

[Bug libgomp/84086] [8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84086

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Confirmed.

#8  find_givs_in_stmt (stmt=0x76735460, data=0x7fffd8a0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-loop-ivopts.c:1446
1446  if (!find_givs_in_stmt_scev (data, stmt, ))
(gdb) p debug_gimple_stmt (stmt)
_14 = 0;

#3  0x00df2f50 in resolve_mixers (loop=0x76a74550, 
chrec=0x767347a0, folded_casts=0x7fffd69e)
at /space/rguenther/src/svn/trunk/gcc/tree-scalar-evolution.c:2840
2840  tree ret = instantiate_scev_r (loop_preheader_edge (loop), loop,
NULL,
(gdb) l
2835{
2836  global_cache = new instantiate_cache_type;
2837  destr = true;
2838}
2839
2840  tree ret = instantiate_scev_r (loop_preheader_edge (loop), loop,
NULL,
2841 chrec, _conversions, 0);
2842
2843  if (folded_casts && !*folded_casts)
2844*folded_casts = fold_conversions;
(gdb) p chrec
$5 = (tree) 0x767347a0
(gdb) p debug_generic_expr ($5)
(sizetype) _21
$6 = void
(gdb) p debug_tree ($5)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x768a6000 precision:64 min  max >

arg:0 >
$7 = 10


so another case of stale SCEV cache.