On 7/28/2026 4:58 PM, Roger Sayle wrote:
-----Original Message-----
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.
jeff
