[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #24 from Gerald Pfeifer --- Confirmed for i386-unknown-freebsd10.3 (using clang as bootstrap compiler) as well. Thank you, Richard!
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #22 from Richard Biener --- > Fixed. Indeed: I've just successfully completed a i386-pc-solaris2.11 bootstrap without the workaround (preloaded libumem.so), and a sparc-sun-solaris2.11 bootstrap is well into make check. Thanks a lot. Rainer
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #21 from Richard Biener --- *** Bug 87271 has been marked as a duplicate of this bug. ***
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from Richard Biener --- Fixed.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #20 from Richard Biener --- Author: rguenth Date: Thu Sep 13 11:31:58 2018 New Revision: 264268 URL: https://gcc.gnu.org/viewcvs?rev=264268=gcc=rev Log: 2018-09-13 Richard Biener PR bootstrap/87134 * tree-ssa-sccvn.c (vn_nary_op_insert_into): Fix assert. (vn_nary_op_insert_pieces_predicated): Do not write useless valid_dominated_by_p entry outside of the allocated storage. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #19 from Richard Biener --- So I have now, with FreeBSD 10.4, bootstrap with host GCC 6.4.0, a libc built with -g -O0 (eh...): Starting program: /root/obj/gcc/cc1 -quiet -fpreprocessed cp-demangle.i -quiet -dumpbase cp-demangle.c -mtune=pentium -march=pentium -auxbase-strip cp-demangle.o -g -O2 -Wno-error -version -fPIC -o cp-demangle.s GNU C17 (GCC) version 9.0.0 20180913 (experimental) (i586-unknown-freebsd10.4) compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C17 (GCC) version 9.0.0 20180913 (experimental) (i586-unknown-freebsd10.4) compiled by GNU C version 6.4.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 7de01f066f6d84094dfef092696e3ed8 Program received signal SIGSEGV, Segmentation fault. 0x2a5bbb3f in __jemalloc_arena_dalloc_bin_locked (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, mapelm=0x2ac02220) at jemalloc_arena.c:1717 1717bin->stats.allocated -= size; (gdb) bt #0 0x2a5bbb3f in __jemalloc_arena_dalloc_bin_locked (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, mapelm=0x2ac02220) at jemalloc_arena.c:1717 #1 0x2a5bc2d6 in __jemalloc_arena_dalloc_bin (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, pageind=729, mapelm=0x2ac02220) at jemalloc_arena.c:1733 #2 0x2a5bc371 in __jemalloc_arena_dalloc_small (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, pageind=729) at jemalloc_arena.c:1749 #3 0x2a5d3913 in __jemalloc_arena_dalloc (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, try_tcache=true) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:1005 #4 __jemalloc_idallocx (ptr=, try_tcache=, ptr=, try_tcache=) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:913 #5 __jemalloc_iqallocx (ptr=0x2aed9000, try_tcache=true) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:932 #6 __jemalloc_iqalloc (ptr=0x2aed9000) at /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/jemalloc_internal.h:939 #7 __free (ptr=0x2aed9000) at jemalloc_jemalloc.c:1277 #8 0x097d59d5 in dom_walker::dom_walker (this=0xbfbfe6b4, direction=CDI_DOMINATORS, reachability=dom_walker::ALL_BLOCKS) at ../../trunk/gcc/domwalk.c:236 #9 0x08e7cf6b in eliminate_dom_walker::eliminate_dom_walker (this=0xbfbfe6b4, direction=CDI_DOMINATORS, inserted_exprs_=0x0) at ../../trunk/gcc/tree-ssa-sccvn.c:4693 #10 0x08e80199 in eliminate_with_rpo_vn (inserted_exprs=0x0) at ../../trunk/gcc/tree-ssa-sccvn.c:5546 #11 0x08e839b4 in do_rpo_vn (fn=0x2b197680, entry= 2)>, exit_bbs=0x0, iterate=true, eliminate=true) at ../../trunk/gcc/tree-ssa-sccvn.c:6613 #12 0x08e83b1f in (anonymous namespace)::pass_fre::execute (this=0x2ac5b8c0, fun=0x2b197680) at ../../trunk/gcc/tree-ssa-sccvn.c:6681 #13 0x08ab9021 in execute_one_pass (pass=) at ../../trunk/gcc/passes.c:2446 This is just int *postorder = XNEWVEC (int, n_basic_blocks_for_fn (cfun)); int postorder_num = pre_and_rev_post_order_compute (NULL, postorder, true); m_bb_to_rpo = XNEWVEC (int, last_basic_block_for_fn (cfun)); for (int i = 0; i < postorder_num; ++i) m_bb_to_rpo[postorder[i]] = i; free (postorder); ^^^ #0 0x2a5bbb3f in __jemalloc_arena_dalloc_bin_locked (arena=0x2a8000c0, chunk=0x2ac0, ptr=0x2aed9000, mapelm=0x2ac02220) at jemalloc_arena.c:1717 1717bin->stats.allocated -= size; (gdb) p bin $1 = (arena_bin_t *) 0x1 where bin is computed as 1697pageind = ((uintptr_t)ptr - (uintptr_t)chunk) >> LG_PAGE; 1698run = (arena_run_t *)((uintptr_t)chunk + (uintptr_t)((pageind - 1699arena_mapbits_small_runind_get(chunk, pageind)) << LG_PAGE)); 1700bin = run->bin; just watching run->bin luckily(?) shows up Hardware watchpoint 5: *$6 Old value = (arena_bin_t *) 0x2a800abc New value = (arena_bin_t *) 0x1 vn_nary_op_insert_pieces_predicated (length=2, code=GT_EXPR, type= , ops=0xbfbfe628, result=, value_id=0, pred_e= 443)>) at ../../trunk/gcc/tree-ssa-sccvn.c:3220 3220 return vn_nary_op_insert_into (vno1, valid_info->nary, true); (gdb) l 3215 vno1->u.values->next = NULL; 3216
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Eric Botcazou --- >> > On SPARC/Solaris? >> >> Yes please, on an arbitrary input you see the segbus/segfault. > > It was a rhetorical question, there is no valgrind on this platform... But > I'll debug the issue at some point, no worries. Even on Solaris 11/x86, where the latest valgrind release (or the git version) is supposed to be supported, I get only failures when running make regtest.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #17 from Eric Botcazou --- > > On SPARC/Solaris? > > Yes please, on an arbitrary input you see the segbus/segfault. It was a rhetorical question, there is no valgrind on this platform... But I'll debug the issue at some point, no worries.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #16 from Martin Liška --- (In reply to Eric Botcazou from comment #15) > > Could you please run compiler in valgrind? > > On SPARC/Solaris? Yes please, on an arbitrary input you see the segbus/segfault.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #15 from Eric Botcazou --- > Could you please run compiler in valgrind? On SPARC/Solaris?
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #14 from Martin Liška --- (In reply to Eric Botcazou from comment #13) > I have random SIGBUS errors on SPARC/Solaris 10 and 11 machines. Could you please run compiler in valgrind?
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #13 from Eric Botcazou --- I have random SIGBUS errors on SPARC/Solaris 10 and 11 machines.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Richard Biener --- > So I've applied a patch that might fix the originally reported segfault. It doesn't help unfortunately: I'm still seeing SEGVs on both i386-pc-solaris2.11 +===GNAT BUG DETECTED==+ | 9.0.0 20180905 (experimental) [trunk revision 264125] (i386-pc-solaris2.11) GCC error:| | in df_bb_refs_record, at df-scan.c:3342 | | Error detected around /vol/gcc/src/hg/trunk/local/gcc/ada/sem_prag.adb:24943:8| raised CONSTRAINT_ERROR : SIGSEGV (which goes away if repeating the compilation manually) and 0x9797fc8 crash_signal /vol/gcc/src/hg/trunk/local/gcc/toplev.c:325 0x99c859a get_expr_value_id /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-pre.c:657 0x99c8bce bitmap_value_insert_into_set /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-pre.c:886 0x99cff53 compute_avail /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-pre.c:3845 0x99d0e3e execute /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-pre.c:4213 building cse.o. On sparc-sun-solaris2.11, I get 0x16a0857 crash_signal /vol/gcc/src/hg/trunk/local/gcc/toplev.c:325 make[3]: *** [Makefile:: ipa-inline-transform.o] Error 1
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #11 from Richard Biener --- So I've applied a patch that might fix the originally reported segfault.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Sep 5 11:44:13 2018 New Revision: 264125 URL: https://gcc.gnu.org/viewcvs?rev=264125=gcc=rev Log: 2018-09-05 Richard Biener PR bootstrap/87134 * tree-ssa-sccvn.c (rpo_elim::eliminate_push_avail): Make sure to zero-init the emplaced vec. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE > 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? > > Sure: I can try with GCC 8.1.0, too. Just did that on i386-pc-solaris2.11: same ICE in compute_fn_summary, at ipa-fnsummary.c:2492.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from rguenther at suse dot de --- [...] >> > 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? Sure: I can try with GCC 8.1.0, too.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #7 from 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 Uni-Bielefeld.DE> --- > > --- Comment #5 from 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 = > > 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?
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from 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 = 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.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #5 from rguenther at suse dot de --- On Thu, 30 Aug 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 > > --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > > --- Comment #2 from Richard Biener --- > > You also might want to test the patch from PR87132. > > I had it in my tree already last night. I've now retried the exact same > tree without libumem, and now get an ICE in stage2 compiling gimplify.c: OK, so at least that one cannot be caused by stage1 miscompiling stage2 cc1[plus]. I wonder if you can run the testsuite in the not bootstrapped tree and look for sth suspicious. 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 = > during IPA pass: fnsummary > /vol/gcc/src/hg/trunk/local/gcc/gimplify.c: In function ‘void > gimplify_scan_omp_clauses(tree_node**, gimple**, omp_region_type, tree_code)’: > /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:13162:1: internal compiler error: > in > compute_fn_summary, at ipa-fnsummary.c:2492 > 13162 | } > | ^ > 0x9400a42 compute_fn_summary(cgraph_node*, bool) > /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:2492 > 0x94029f2 inline_analyze_function(cgraph_node*) > /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3146 > 0x9402b8c ipa_fn_summary_generate > /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3189 > 0x956db21 execute_ipa_summary_passes(ipa_opt_pass_d*) > /vol/gcc/src/hg/trunk/local/gcc/passes.c:2149 > 0x9161451 ipa_passes > /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2432 > 0x91617c4 symbol_table::compile() > /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2543 > 0x9161e4b symbol_table::finalize_compilation_unit() > /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2788 Given this is the stage1 compiler complaining it looks unrelated. What's your host compiler? Do you use custom STAGE1_CFLAGS?
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Richard Biener --- > You also might want to test the patch from PR87132. I had it in my tree already last night. I've now retried the exact same tree without libumem, and now get an ICE in stage2 compiling gimplify.c: during IPA pass: fnsummary /vol/gcc/src/hg/trunk/local/gcc/gimplify.c: In function ‘void gimplify_scan_omp_clauses(tree_node**, gimple**, omp_region_type, tree_code)’: /vol/gcc/src/hg/trunk/local/gcc/gimplify.c:13162:1: internal compiler error: in compute_fn_summary, at ipa-fnsummary.c:2492 13162 | } | ^ 0x9400a42 compute_fn_summary(cgraph_node*, bool) /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:2492 0x94029f2 inline_analyze_function(cgraph_node*) /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3146 0x9402b8c ipa_fn_summary_generate /vol/gcc/src/hg/trunk/local/gcc/ipa-fnsummary.c:3189 0x956db21 execute_ipa_summary_passes(ipa_opt_pass_d*) /vol/gcc/src/hg/trunk/local/gcc/passes.c:2149 0x9161451 ipa_passes /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2432 0x91617c4 symbol_table::compile() /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2543 0x9161e4b symbol_table::finalize_compilation_unit() /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2788
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #2 from Richard Biener --- You also might want to test the patch from PR87132. --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Richard Biener --- > If you disable bootstrap does it work? The backtrace makes it look like > memory > corruption. Maybe you can also throw valgrind on it? A --disable-bootstrap build (c, c++ only) does work on i386-pc-solaris2.11, but I didn't run make check. While there is a Solaris/x86 valgrind port, I haven't used it yet (and it seems I'll have to use the git version on Solaris 11.4). For a start, I ran the failing compilation with libumem (a debugging malloc) preloaded and UMEM_DEBUG=default: this way, the compilation succeeded without errors. Afterwards, I managed to bootstrap with just LD_PRELOAD=libumem.so on both i386-pc-solaris2.11 and sparc-sun-solaris2.11. That completed successfully, but 200+ 32-bit Go tests now FAIL, together with two 64-bit libstdc++ max_align_t tests. Since there are already similar Go failures with the libc malloc, I'm pretty sure this is just uncovering a preexisting libgo bug. I'll try what I can find with valgrind next.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #2 from Richard Biener --- You also might want to test the patch from PR87132.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #1 from Richard Biener --- If you disable bootstrap does it work? The backtrace makes it look like memory corruption. Maybe you can also throw valgrind on it?
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
