RE: [CRIS PATCH] PR rtl-optimization/126276: Restore build on cris-elf.

> 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
--