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

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 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=/export/users3/haochenj/src/gcc-bisect/master/master/r17-2354/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
> 
> To reproduce:
> 
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr124407-1.c --target_board='unix{-m64}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr124407-1.c --target_board='unix{-m64\ -march=cascadelake}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr81501-9b.c --target_board='unix{-m64}'"
> $ cd {build_dir}/gcc && make check RUNTESTFLAGS="i386.exp=gcc.target/i386/pr81501-9b.c --target_board='unix{-m64\ -march=cascadelake}'"
> 
> (Please directly reply to this email for question about this report.)
> (If you met problems with cascadelake related, disabling AVX512F in command line might save that.)
> (However, please make sure that there is no potential problems with AVX512.)
Hi Haochen,

Thank you for pointing this out. Having reproduced all 3 failures 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 rearranges 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=r115:V2SF#0
      REG_DEAD r115:V2SF
   13: r112:V4SF=const_vector
   16: r114:V4SF=r113: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/work/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.