On Thu, Aug 22, 2024 at 12:32 PM John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: > > (Please CC me in the replies, I am not subscribed to the list) > > Hi, > > I am currently trying to switch the SH backend to use the LRA register > allocater > by default with the help of patches by Oleg and Kaz (CC'ed) to address various > issues when using LRA by default. The patches can all be found in the > corresponding > Bugzilla report [1]. > > Currently, I have applied the following patches from the bug report: > > - 58832 > - 58833 > - 58883 > - 58905 > > plus the following change to enable LRA by default: > > diff --git a/gcc/config/sh/sh.opt b/gcc/config/sh/sh.opt > index c44cfe70cb1..718dfb744ff 100644 > --- a/gcc/config/sh/sh.opt > +++ b/gcc/config/sh/sh.opt > @@ -299,5 +299,5 @@ Target Var(TARGET_FSRRA) > Enable the use of the fsrra instruction. > > mlra > -Target Var(sh_lra_flag) Init(0) Save > +Target Var(sh_lra_flag) Init(1) Save > Use LRA instead of reload (transitional). > > With these changes applied, I have configured and built GCC from Git as > follows: > > # ../configure --disable-multilib --enable-multiarch --enable-bootstrap > --enable-languages=c,c++ > # make -j32 > > which fails on QEMU with a segmentation fault: > > /srv/glaubitz/gcc/build/./gcc/xgcc -B/srv/glaubitz/gcc/build/./gcc/ > -B/usr/local/sh4-unknown-linux-gnu/bin/ \ > -B/usr/local/sh4-unknown-linux-gnu/lib/ -isystem > /usr/local/sh4-unknown-linux-gnu/include -isystem \ > /usr/local/sh4-unknown-linux-gnu/sys-include -fno-checking -g -O2 -O2 -g > -O2 -DIN_GCC \ > -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes > -Wmissing-prototypes \ > -Wold-style-definition -isystem ./include -fpic -DNO_FPSCR_VALUES -w > -Wno-sync-nand -g -DIN_LIBGCC2 \ > -fbuilding-libgcc -fno-stack-protector -fpic -DNO_FPSCR_VALUES -w > -Wno-sync-nand -I. -I. \ > -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc > -I../../../libgcc/../include \ > -DHAVE_CC_TLS -o _paritysi2.o -MT _paritysi2.o -MD -MP -MF _paritysi2.dep > -DL_paritysi2 \ > -c ../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS > during GIMPLE pass: waccess > ../../../libgcc/libgcc2.c: In function '__muldi3': > ../../../libgcc/libgcc2.c:538:1: internal compiler error: Segmentation fault > 538 | } > | ^ > during GIMPLE pass: waccess
If this is stage2 or stage3 it hints at a miscompile of the stage2/3 compiler. I'd concentrate on other issues first and suggest to use --disable-bootstrap to see if that gets you to running the testsuite. Otherwise you need to bisect which stage2/3 object was miscompiled and then investigate the nature of the miscompilation. A much more tedious process than addressing remaining testsuite execution FAILs. Richard. > This is reproducible on real hardware (Renesas SH-7785LCR, Linux 6.5.0), so > it's not an emulation issue. > > I have tried to debug this issue with my Linux-SH-enabled GDB fork [2] and > got the following backtrace: > > (gdb) bt > #0 0x0109fee4 in wi::add_large(long long*, long long const*, unsigned int, > long long const*, unsigned int, unsigned int, signop, wi::overflow_type*) () > #1 0x00bdbc10 in > access_ref::add_offset(generic_wide_int<fixed_wide_int_storage<128> > const&, > generic_wide_int<fixed_wide_int_storage<128> > const&) () > #2 0x00bdd0e8 in compute_objsize_r(tree_node*, gimple*, bool, int, > access_ref*, ssa_name_limit_t&, pointer_query*) () > #3 0x00000000 in ?? () > (gdb) display/i $pc > 1: x/i $pc > => 0x109fee4 <_ZN2wi9add_largeEPxPKxjS2_jj6signopPNS_13overflow_typeE+84>: > mov.l @r2,r3 > (gdb) x/wx $r2 > 0x7c07eaa0: Cannot access memory at address 0x7c07eaa0 > (gdb) > > I have also tried disabling late combine by SH by default, but that didn't > help: > > diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc > index 280588268ae..dca27893536 100644 > --- a/gcc/config/sh/sh.cc > +++ b/gcc/config/sh/sh.cc > @@ -1047,6 +1047,9 @@ sh_override_options_after_change (void) > str_align_functions = r; > } > } > + > + if (!OPTION_SET_P (flag_late_combine_instructions)) > + flag_late_combine_instructions = 0; > } > ^L > /* Print the operand address in x to the stream. */ > > Thus, I have now run out of ideas (as I'm not really a compiler expert). > > Does anyone else have any other suggestions? > > Thanks, > Adrian > > PS: Would be great if we could upstream Linux SH native GDB support from [2] > as well, in case any binutils-gdb maintainer is reading here. > > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 > > [2] https://github.com/glaubitz/binutils-gdb/tree/linux-sh > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
