[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94 (tree-switch-conversion.cc miscompiled)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #20 from John Paul Adrian Glaubitz --- I've tried Jeff's patch from the mailing list [1] on top of GCC 14 and I'm still seeing that segmentation fault. > [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657104.html
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #19 from Thorsten Otto --- I've already done that, as shown above in comment #7.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #18 from Jeffrey A. Law --- And I'll repeat what I said earlier. Someone is going to have to put this under a debugger and understand what's really going on. As far as I can tell that's never been done and while debugging via "i did this and it failed" can work, it's not terrible efficient. So again, I would suggest someone with an interest start by putting the failing stage2 compiler under the debugger to understand why the fault is triggering. That will also provide a bit more insight into what routine is most likely problematical.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #17 from Jeffrey A. Law --- It's actually pretty damn simple. ../../gcc/configure --disable-analyzer --prefix=$PREFIX --enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer m68k-linux-gnu
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #16 from Sam James --- (In reply to Jeffrey A. Law from comment #11) Jeff, could you show me your tester's configuration so I can compare the two? Thank you!
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 Sam James changed: What|Removed |Added See Also||https://bugs.gentoo.org/sho ||w_bug.cgi?id=932733 --- Comment #15 from Sam James --- We're seeing this downstream in Gentoo too: https://bugs.gentoo.org/932733.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #14 from Mikael Pettersson --- Since gcc-15 wouldn't build due to an unrelated issue, I applied the fmo patch to gcc-14.1 (which also has this bug) and bootstrapped that. Alas it didn't make any difference, same error in stage2 as in the initial report.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #13 from Mikael Pettersson --- (In reply to Mikael Pettersson from comment #9) > (In reply to Manolis Tsamis from comment #8) > > Created attachment 58335 [details] > > Do not modify live_out registers > > > > After looking again at the dumps from PR112415, which I believe is closely > > related to the issue here, I saw that while f-m-o was checking the uses of > > the folded registers, it was still modifying registers that were at the BB's > > live_out set. > > > > I have attached a patch that I'm testing for addressing this. Could you > > please check if this fixes this issue? > > I'm starting a bootstrap on m68k-linux-gnu with this now, should know by > Friday if it resolves the issue or not. (It's running in full-system > emulation mode on Aranym, so it's slow.) Failed with a compile-warning-turned-error, haven't had time to investigate. In file included from /mnt/scratch/gcc-15-20240602/gcc/system.h:726, from /mnt/scratch/gcc-15-20240602/gcc/gimple-range-edge.cc:24: In member function 'wide_int_storage& wide_int_storage::operator=(const T&) [with T = wi::hwi_with_prec]', inlined from 'generic_wide_int& generic_wide_int::operator=(const T&) [with T = wi::hwi_with_prec; storage = wide_int_storage]' at /mnt/scratch/gcc-15-20240602/gcc/wide-int.h:1002:23, inlined from 'void irange_bitmask::set_unknown(unsigned int)' at /mnt/scratch/gcc-15-20240602/gcc/value-range.h:165:27, inlined from 'virtual void irange::set_varying(tree)' at /mnt/scratch/gcc-15-20240602/gcc/value-range.h:1140:25, inlined from 'int_range::int_range(tree) [with unsigned int N = 3; bool RESIZABLE = true]' at /mnt/scratch/gcc-15-20240602/gcc/value-range.h:1102:15, inlined from 'void gimple_outgoing_range::calc_switch_ranges(gswitch*)' at /mnt/scratch/gcc-15-20240602/gcc/gimple-range-edge.cc:140:36: /mnt/scratch/gcc-15-20240602/gcc/wide-int.h:1241:23: error: 'default_range.int_range<3, true>::.irange::m_bitmask.irange_bitmask::m_value.generic_wide_int::.wide_int_storage::u.wide_int_storagevalp' may be used uninitialized [-Werror=maybe-uninitialized] 1241 | XDELETEVEC (u.valp); /mnt/scratch/gcc-15-20240602/gcc/../include/libiberty.h:370:48: note: in definition of macro 'XDELETEVEC' 370 | #define XDELETEVEC(P) free ((void*) (P)) |^ /mnt/scratch/gcc-15-20240602/gcc/gimple-range-edge.cc: In member function 'void gimple_outgoing_range::calc_switch_ranges(gswitch*)': /mnt/scratch/gcc-15-20240602/gcc/gimple-range-edge.cc:140:17: note: 'default_range' declared here 140 | int_range_max default_range (type); | ^ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:1197: gimple-range-edge.o] Error 1
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #12 from Thorsten Otto --- Can you try to compile the date_is_valid() snippet in comment#7?
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #11 from Jeffrey A. Law --- That's not the way we do things. And my bootstraps on m68k are working fine. Last one was 6 days ago. This needs to be debugged by someone with the time/interest on the m68k.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #10 from Thorsten Otto --- In my case it didn't fix the issue. I still get internal compiler error: in emit, at tree-switch-conversion.cc:1637 when i configure it atleast with --enable-checking=misc So i can just repeat myself: if even after 3-4 attempts of fixing this it still does not work, please revert that fold-mem-offset patch(es), or atleast disable them. Its not worth of doing unsafe optimizations whose only purpose is to save a single instruction for a particular machine, but cause trouble for others.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #9 from Mikael Pettersson --- (In reply to Manolis Tsamis from comment #8) > Created attachment 58335 [details] > Do not modify live_out registers > > After looking again at the dumps from PR112415, which I believe is closely > related to the issue here, I saw that while f-m-o was checking the uses of > the folded registers, it was still modifying registers that were at the BB's > live_out set. > > I have attached a patch that I'm testing for addressing this. Could you > please check if this fixes this issue? I'm starting a bootstrap on m68k-linux-gnu with this now, should know by Friday if it resolves the issue or not. (It's running in full-system emulation mode on Aranym, so it's slow.)
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #8 from Manolis Tsamis --- Created attachment 58335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58335=edit Do not modify live_out registers After looking again at the dumps from PR112415, which I believe is closely related to the issue here, I saw that while f-m-o was checking the uses of the folded registers, it was still modifying registers that were at the BB's live_out set. I have attached a patch that I'm testing for addressing this. Could you please check if this fixes this issue?
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
Thorsten Otto changed:
What|Removed |Added
CC||ad...@tho-otto.de
--- Comment #7 from Thorsten Otto ---
I ran into a similar problem. The symptom was that code in
tree-switch-conversion was miscompiled:
if (k == count)
{
gcc_checking_assert (count < m_max_case_bit_tests);
test[k].mask = wi::zero (prec);
test[k].target_bb = n->m_case_bb;
test[k].label = n->m_case_label_expr;
test[k].bits = 0;
test[k].prob = profile_probability::never ();
count++;
}
--- good.s 2024-06-02 13:20:13.453987931 +0200
+++ bad.s 2024-06-02 13:50:03.452881214 +0200
@@ -26976,11 +26976,10 @@
move.l %d1,-330(%a0)| prephitmp_336, MEM
[(struct wide_int_storage *)][count_1036].mask.D.16112.len
| gcc/tree-switch-conversion.cc:1639: test[k].target_bb =
n->m_case_bb;
move.l 4(%a3),%d1 | MEM [(void *)n_1051
+ 4B], vect__12.3140
- lea (-322,%fp),%a4 |,,
- lea (%a4,%d0.l),%a1 |, vectp.3143
+ lea (%fp,%d0.l),%a1 | tmp12, tmp638, vectp.3143
| gcc/tree-switch-conversion.cc:1639: test[k].target_bb =
n->m_case_bb;
move.l 8(%a3),(%a1) | MEM [(void *)n_1051
+ 8B], MEM [(void *)vectp.3143_425]
- move.l %d1,4(%a1) | vect__12.3140, MEM
[(void *)vectp.3143_425 + 4B]
+ move.l %d1,-318(%a1)| vect__12.3140, MEM
[(void *)vectp.3143_425 + 4B]
| gcc/tree-switch-conversion.cc:1641: test[k].bits = 0;
clr.l -314(%a0) | test[count_1036].bits
| gcc/tree-switch-conversion.cc:1642: test[k].prob =
profile_probability::never ();
Apparently the offset to the local test array was optimized away for the first
store, causing the outer loop to not find the previous m_case_bb pointer, and
then either crash or fail with an assertion because the array overflowed.
Seems like this is not the first regression caused by this "optimization".
Maybe it should be disabled for targets other than riscv, atleast until more
tests have been written.
A crash with such a buggy compiler can be produced with eg.
int date_is_valid(int mon)
{
switch (mon) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
break;
default:
return 0x2400;
}
return 0;
}
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 Richard Biener changed: What|Removed |Added Target Milestone|14.0|14.2 --- Comment #6 from Richard Biener --- GCC 14.1 is being released, retargeting bugs to GCC 14.2.
