On Thu, Jul 16, 2026 at 01:02:45PM +0800, H.J. Lu wrote: > On Thu, Jul 16, 2026 at 10:21 AM Jiang, Haochen <[email protected]> > wrote: > > > > > From: H.J. Lu <[email protected]> > > > Sent: Thursday, July 16, 2026 9:38 AM > > > > > > On Thu, Jul 16, 2026 at 9:30 AM H.J. Lu <[email protected]> wrote: > > > > > > > > On Wed, Jul 15, 2026 at 11:14 PM 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 > > > > > > 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/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 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. > > > > > > > > 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 need 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 kicks 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 gcc.target/i386/pr124407-1.c - remove register number hardcoding Thanks, Dylan
