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

On Thu, Jul 23, 2026 at 4:52=E2=80=AFPM Dylan Rees <[email protected]> wro=
te:
>
> On Thu, Jul 16, 2026 at 01:02:45PM +0800, H.J. Lu wrote:
> > On Thu, Jul 16, 2026 at 10:21=E2=80=AFAM Jiang, Haochen <haochen.jiang@=
intel.com> wrote:
> > >
> > > > From: H.J. Lu <[email protected]>
> > > > Sent: Thursday, July 16, 2026 9:38 AM
> > > >
> > > > On Thu, Jul 16, 2026 at 9:30=E2=80=AFAM H.J. Lu <[email protected]=
m> wrote:
> > > > >
> > > > > On Wed, Jul 15, 2026 at 11:14=E2=80=AFPM Dylan Rees <dylan.rees@a=
rm.com>
> > > > 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 dif=
ferent vector
> > > > widths
> > > > > > >
> > > > > > > caused
> > > > > > >
> > > > > > > FAIL: gcc.target/i386/pr124407-1.c scan-rtl-dump x86_cse "\\(=
const_int
> > > > 0 \\[0\\]\\) repeated x16"
> > > > > > > FAIL: gcc.target/i386/pr124407-1.c scan-rtl-dump x86_cse "\\(=
set
> > > > \\(reg: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/gc=
c-
> > > > bisect/master/master/r17-2354/usr --enable-clocale=3Dgnu --with-sys=
tem-zlib -
> > > > -with-demangler-in-ld --with-fpmath=3Dsse --enable-languages=3Dc,c+=
+,fortran --
> > > > enable-cet --without-isl --enable-libmpx x86_64-linux --disable-boo=
tstrap
> > > > > > >
> > > > > > > To reproduce:
> > > > > > >
> > > > > > > $ cd {build_dir}/gcc && make check
> > > > RUNTESTFLAGS=3D"i386.exp=3Dgcc.target/i386/pr124407-1.c --
> > > > target_board=3D'unix{-m64}'"
> > > > > > > $ cd {build_dir}/gcc && make check
> > > > RUNTESTFLAGS=3D"i386.exp=3Dgcc.target/i386/pr124407-1.c --
> > > > target_board=3D'unix{-m64\ -march=3Dcascadelake}'"
> > > > > > > $ cd {build_dir}/gcc && make check
> > > > RUNTESTFLAGS=3D"i386.exp=3Dgcc.target/i386/pr81501-9b.c --
> > > > target_board=3D'unix{-m64}'"
> > > > > > > $ cd {build_dir}/gcc && make check
> > > > RUNTESTFLAGS=3D"i386.exp=3Dgcc.target/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 AVX5=
12F in
> > > > command line might save that.)
> > > > > > > (However, please make sure that there is no potential problem=
s with
> > > > AVX512.)
> > > > > > Hi Haochen,
> > > > > >
> > > > > > Thank you for pointing this out. Having reproduced all 3 failur=
es I realise 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 rearrange=
s the
> > > > order in a sensible way but there
> > > > > > is a 'check-function-bodies' enforcing a certain structure.
> > ...
> > > >
> > > > > > 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 see=
ms 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/work/505bfdd4dad8af3d/gcc/testsuite/gcc.target/i38=
6/pr
> > > > 124407-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 wh=
at the
> > > > upper bits are.
> > > > > > Codegen appears better or the same, but as a result of the para=
doxical
> > > > subreg the code looks a bit strange.
> > > > >
> > >
> > > Hi H.J.,
> > >
> > > I have not looked into it for all three cases. But whatever happened,=
  should
> > > we at least change the (reg:V16QI 125) check? I did not get why we ne=
ed to
> > > check exact number 125. Is it on purpose? I also have patches from my=
 side
> > > breaks this by outputting another number.
> > >
> >
> > It doesn't match since it scans for x86_cse results which no longer kic=
ks in.
> >
> > --
> > H.J.
> Hi H.J.,
>
> Are we in agreement that both tests should be adjusted?
>
> gcc.target/i386/pr81501-9b.c - remove the explicit ordering

Please show your change.

> gcc.target/i386/pr124407-1.c - remove register number hardcoding
>

What does this change look like?


--=20
H.J.