On Thu, Jul 23, 2026 at 4:52 PM Dylan Rees <[email protected]> wrote: > > 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
Please show your change. > gcc.target/i386/pr124407-1.c - remove register number hardcoding > What does this change look like? -- H.J.
