> From: Jeffrey Law <[email protected]> > Sent: 29 July 2026 14:30 > To: Roger Sayle <[email protected]>; 'Patches GCC' <gcc- > [email protected]> > Cc: 'Hans-Peter Nilsson' <[email protected]> > Subject: Re: [CRIS PATCH] PR rtl-optimization/126276: Restore build on > cris-elf. > > On 7/28/2026 4:58 PM, Roger Sayle wrote: > >> From: Jeffrey Law <[email protected]> > >> Sent: 27 July 2026 20:03 > >> To: Roger Sayle <[email protected]>; 'Patches GCC' <gcc- > >> [email protected]> > >> Cc: 'Hans-Peter Nilsson' <[email protected]> > >> Subject: Re: [CRIS PATCH] PR rtl-optimization/126276: Restore build on > >> cris-elf. > >> > >> On 7/27/2026 2:44 AM, Roger Sayle wrote: > >>> This patch resolves PR rtl-optimization/126276 which is a > >>> target-specific regression on CRIS, triggered by a recent RTL > >>> simplification > >> improvement. > >>> The underlying problem is that cris.md's > >>> *cbranch<mode>4_btstrq1_<CC> accepts more machines modes than the > define_insn it is lowering to. > >>> Fixed by adding the necessary modes to the *btst<mode> define_insn. > >>> > >>> This change restores the ability to build a cross-compiler to > >>> cris-elf, and generates the same code for Jeff's reduced test case as > previously. > >>> Tested by building an uber-tree to cris-elf from > >>> x86_64-pc-linux-gnu, with make and make -k check, with no new > >>> failures relative to a baseline that has the triggering > >>> simplify-rtx.cc change reverted. Ok for > >> mainline? > >>> > >>> 2026-07-27 Roger Sayle <[email protected]> > >>> > >>> gcc/ChangeLog > >>> PR target/126276 > >>> * config/cris/cris.md (*btst<BWD><ZnNNZSET): Handle BWD modes, > >>> not just SImode. > >>> (*cbranch<mode>4_btstrq1_<CC>): Likewise. > >>> (*cbranch<mode>4_btstqb0_<CC>): Likewise. > >>> > >>> Thanks in advance and sorry for the inconvenience. > >> Thanks. Threw that into my tester, the build succeeds, so that's > >> progress. However, I am seeing regressions relative to the prior good > >> run. I > can't > >> trivially cut-and-paste them over, but I bet if you started with > >> either > >> gcc.dg/constructor-1 or gcc.dg/ipa/pr70306 you'd likely cover the > >> initpri tests over in c-c++-common that have also regressed. These > >> were execution failures, so hoping there'd be a diff in the generated > >> assembly code, else it could be in the library. Also note, it's been > >> a week or two with no results, so it's even possible there's some other bug > that's snuck into the tree affecting cris. > > Is it possible that it has been more than a week or two since your > > last cris-elf results? I've been investigating gcc.dg/constructor-1.c > > both with and without reverting the original (triggering) > > simplify-rtx.cc change and not only do they produce identical assembly > > language output, but as a stable control I also compared to the last > > GCC release, gcc-16.1.0, which also produces identical assembly > > output. I'd be surprised if my original change or the cris-elf fix > > affect this problem, as the -fdump-rtl-combine shows the code contains > > no zero_extracts (or zero_extends or sign_extracts), and doesn't > > generate/use a > btst instruction. > It was roughly 2 weeks ago (July 14/15 timeframe). Thankfully I keep > ~30 builds, so the last clean build is still available and I do record a > manifest of > hashes. > > binutils-gdb bda8f339d129a2ddeff0214f47109e8df7aa7e29 > gcc 2dbb4c5db7020ab59e81d7a3e190c1c690411b82 > newlib-cygwin 1a651fdb3c08e46b988f149b7b206798abc2bc82 > patches a1022c00cef2c18bca22c6edc56eac6c962280a5 > > > Might it be a change in binutils or sim around global constructors on > > cris-elf? > > or possibly with "{ dg-skip-if "" { ! global_constructor } }" in the > > testsuite. > > > > Thanks in advance for your thoughts. Perhaps we should open a Bugzilla PR? > Yea, let's get that BZ opened. Given the length of time it's entirely > possible > something else is playing a role. It's not automatic, but I can recreate a > build > with the hashes above and just apply your two patches (the one that caused the > cris build failure and the fix) to isolate those from anything else going on. > It won't > happen this week as I'm on the road (hence the desire to get that BZ open). > > Note carefully there is a "patches" repo which contains my own in-flight > stuff, > workarounds for flakey port issues, dejagnu bits, etc etc. So there's a > small, but > not zero chance that's playing a role as well. Usually the first step I do > when > reporting an issue is back out anything that isn't in the upstream repos. > While I > did that for the initial bug report, I didn't do it for the testsuite > failures we're > seeing now.
FYI, this has now been filed at PR target/126518. My thanks to both you and H-P. Roger --
