> -----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.
I've modified constructor-1.c to avoid the #include <stdlib.h> dependency:
int x, y;
void __attribute__((noinline))
bar(void)
{
y++;
}
void __attribute__((constructor))
foo(void)
{
if (!x)
{
bar();
y++;
}
}
int main()
{
x = 1;
foo();
foo();
if (y != 2)
__builtin_abort();
__builtin_exit(0);
}
And the (consistently) generated code looks like:
#NO_APP
.file "constructor-1.c"
.text
.align 1
.global _bar
.type _bar, @function
_bar:
move.d [_y],$r9
addq 1,$r9
move.d $r9,[_y]
ret
nop
.size _bar, .-_bar
.section .text.startup,"ax",@progbits
.align 1
.global _foo
.type _foo, @function
_foo:
subq 4,$sp
move $srp,[$sp]
test.d [_x]
beq .L5
nop
jump [$sp+]
.L5:
jsr _bar
move.d [_y],$r9
addq 1,$r9
move.d $r9,[_y]
jump [$sp+]
.size _foo, .-_foo
.section .ctors,"aw",@progbits
.align 2
.dword _foo
.section .text.startup
.align 1
.global _main
.type _main, @function
_main:
subq 4,$sp
move $srp,[$sp]
subq 4,$sp
move.d $r0,[$sp]
moveq 1,$r9
move.d $r9,[_x]
move.d _foo,$r0
jsr $r0
jsr $r0
move.d [_y],$r9
cmpq 2,$r9
bne .L8
clear.d $r10
jsr _exit
.L8:
jsr _abort
.size _main, .-_main
.global _y
.section .bss,"aw",@nobits
.align 1
.type _y, @object
.size _y, 4
_y:
.zero 4
.global _x
.align 1
.type _x, @object
.size _x, 4
_x:
.zero 4
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?
Cheers,
Roger
--
