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). Besides, I've also tried amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11 bootstraps without libumem: both succeed without issues, so this is a 32-bit thing only.