https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 31 Aug 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 > > --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- > > --- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- > [...] > > I wonder if you can run the testsuite in the not bootstrapped tree > > and look for sth suspicious. > > I did that now (c and c++ only), but nothing sprang to attention. > > > There is uninitialized memory (but it should never be used...) in > > the new VN, so a shot in the dark would be > > > > Index: gcc/tree-ssa-sccvn.c > > =================================================================== > > --- gcc/tree-ssa-sccvn.c (revision 263972) > > +++ gcc/tree-ssa-sccvn.c (working copy) > > @@ -6240,7 +6240,7 @@ do_rpo_vn (function *fn, edge entry, bit > > for (int i = 0; i < n; ++i) > > bb_to_rpo[rpo[i]] = i; > > > > - unwind_state *rpo_state = XNEWVEC (unwind_state, n); > > + unwind_state *rpo_state = XCNEWVEC (unwind_state, n); > > > > rpo_elim avail (entry->dest); > > rpo_avail = &avail; > > Also bootstrapped that right now: doesn't help. Seems I'll have to go > the valgrind route. > > > What's your host compiler? Do you use custom STAGE1_CFLAGS? > > Just a vanilla i386-pc-solaris2.11 gcc 7.1.0. Nothing special > (STAGE1_CFLAGS or other). Hmm, GCC 7.1.0 of course makes me raise eyebrows. Do you by chance have another host compiler to cross-test whether it's a host compiler issue?
