Re: [r17-2354 Regression] FAIL: gcc.target/i386/pr81501-9b.c check-function-bodies foo on Linux/x86_64

On Thu, Jul 16, 2026 at 9:30=E2=80=AFAM H.J. Lu <[email protected]> wrote=
:
>
> On Wed, Jul 15, 2026 at 11:14=E2=80=AFPM Dylan Rees <[email protected]> =
wrote:
> >
> > On Wed, Jul 15, 2026 at 02:22:30PM +0800, Haochen Jiang wrote:
> > > On Linux/x86_64,
> > >
> > > 10f6223d833874199e17226fbb0c562b69a1e72f is the first bad commit
> > > commit 10f6223d833874199e17226fbb0c562b69a1e72f
> > > Author: Dylan Rees <[email protected]>
> > > Date:   Mon Jul 13 09:57:18 2026 +0000
> > >
> > >     middle-end: Eliminate redundant scalar duplication at different v=
ector widths
> > >
> > > caused
> > >
> > > FAIL: gcc.target/i386/pr124407-1.c scan-rtl-dump x86_cse "\\(const_in=
t 0 \\[0\\]\\) repeated x16"
> > > FAIL: gcc.target/i386/pr124407-1.c scan-rtl-dump x86_cse "\\(set \\(r=
eg:V16QI 125\\)"
> > > FAIL: gcc.target/i386/pr81501-9b.c check-function-bodies foo
> > >
> > > with GCC configured with
> > >
> > > ../../gcc/configure --prefix=3D/export/users3/haochenj/src/gcc-bisect=
/master/master/r17-2354/usr --enable-clocale=3Dgnu --with-system-zlib --wit=
h-demangler-in-ld --with-fpmath=3Dsse --enable-languages=3Dc,c++,fortran --=
enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
> > >
> > > To reproduce:
> > >
> > > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.tar=
get/i386/pr124407-1.c --target_board=3D'unix{-m64}'"
> > > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.tar=
get/i386/pr124407-1.c --target_board=3D'unix{-m64\ -march=3Dcascadelake}'"
> > > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.tar=
get/i386/pr81501-9b.c --target_board=3D'unix{-m64}'"
> > > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.tar=
get/i386/pr81501-9b.c --target_board=3D'unix{-m64\ -march=3Dcascadelake}'"
> > >
> > > (Please directly reply to this email for question about this report.)
> > > (If you met problems with cascadelake related, disabling AVX512F in c=
ommand line might save that.)
> > > (However, please make sure that there is no potential problems with A=
VX512.)
> > Hi Haochen,
> >
> > Thank you for pointing this out. Having reproduced all 3 failures I rea=
lise I  was previously aware of them and was
> > intending to inform the appropriate maintainers of these tests.
> >
> > For test 'gcc.target/i386/pr81501-9b.c':
> > This seems to be an overconstrained check as my patch rearranges the or=
der in a sensible way but there
> > is a 'check-function-bodies' enforcing a certain structure.
>
> Before:
>
> foo:
> .LFB7297:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> vpbroadcastb %edi, %zmm0
> leaq var@TLSDESC(%rip), %rax
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> pushq %rbx
> andq $-64, %rsp
> subq $64, %rsp
> .cfi_offset 3, -24
> movq %fs:0, %rdi
> call *var@TLSCALL(%rax)
> vmovdqa64 %zmm0, (%rsp)
> addq %rax, %rdi
> movq %rax, %rbx
> vzeroupper
> call func1@PLT
> call func2@PLT
> vmovdqa64 (%rsp), %zmm0
> testl %eax, %eax
> jne .L8
> .L2:
> movq sinkx@GOTPCREL(%rip), %rax
> vmovdqa %xmm0, (%rax)
> movq sinkz@GOTPCREL(%rip), %rax
> vmovdqa64 %zmm0, (%rax)
> movq sinky@GOTPCREL(%rip), %rax
> vmovdqa %ymm0, (%rax)
> movq %fs:(%rbx), %rax
> vzeroupper
> movq -8(%rbp), %rbx
> leave
> .cfi_remember_state
> .cfi_def_cfa 7, 8
> ret
> .p2align 4,,10
> .p2align 3
> .L8:
> .cfi_restore_state
> vzeroupper
> call func3@PLT
> vmovdqa64 (%rsp), %zmm0
> jmp .L2
> .cfi_endproc
>
> After:
>
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> leaq var@TLSDESC(%rip), %rax
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> pushq %r12
> .cfi_offset 12, -24
> movl %edi, %r12d
> movq %fs:0, %rdi
> pushq %rbx
> andq $-64, %rsp
> .cfi_offset 3, -32
> call *var@TLSCALL(%rax)
> addq %rax, %rdi
> movq %rax, %rbx
> call func1@PLT
> call func2@PLT
> testl %eax, %eax
> jne .L8
> .L2:
> movq sinkx@GOTPCREL(%rip), %rax
> vpbroadcastb %r12d, %zmm0
> vmovdqa %xmm0, (%rax)
> movq sinkz@GOTPCREL(%rip), %rax
> vmovdqa64 %zmm0, (%rax)
> movq sinky@GOTPCREL(%rip), %rax
> vmovdqa %ymm0, (%rax)
> movq %fs:(%rbx), %rax
> vzeroupper
> leaq -16(%rbp), %rsp
> popq %rbx
> popq %r12
> popq %rbp
> .cfi_remember_state
> .cfi_def_cfa 7, 8
> ret
>
> "vpbroadcastb %r12d, %zmm0" is moved into the loop.

There is no loop.  The new code looks OK.

> > For test 'gcc.target/i386/pr124407-1.c':
> > combine (rtl) step tries:
> > '''
> > Trying 15, 13 -> 16:
> >    15: r113:V4SF=3Dr115:V2SF#0
> >       REG_DEAD r115:V2SF
> >    13: r112:V4SF=3Dconst_vector
> >    16: r114:V4SF=3Dr113:V4SF-r112:V4SF
> >       REG_DEAD r113:V4SF
> > '''
> > so it tried simplifying the subtract but target said no and seems to be=
 rejecting the subreg:
> > '''
> > (insn 15 14 16 2 (set (reg:V4SF 113 [ vD.5233 ])
> >         (subreg:V4SF (reg:V2SF 115 [ vD.5233 ]) 0)) "/opt/buildAgent/wo=
rk/505bfdd4dad8af3d/gcc/testsuite/gcc.target/i386/pr124407-1.c":13:5 2466 {=
movv4sf_internal}
> >      (expr_list:REG_DEAD (reg:V2SF 115 [ vD.5233 ])
> > '''
> > The issue is insn 15 is created as a paradoxical subreg before my patch=
 applies so the subtract can't be removed because it doesn't know what the =
upper bits are.
> > Codegen appears better or the same, but as a result of the paradoxical =
subreg the code looks a bit strange.
>
>
>
> --
> H.J.



--=20
H.J.