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.

Reply via email to