On Mon, Dec 11, 2023, 21:48 Jiang, Haochen <[email protected]> wrote:
> > -----Original Message----- > > From: Jiang, Haochen > > Sent: Tuesday, December 12, 2023 9:11 AM > > To: Andrew Pinski (QUIC) <[email protected]>; haochen.jiang > > <[email protected]>; [email protected]; gcc- > > [email protected] > > Subject: RE: [r14-6420 Regression] FAIL: gcc.target/i386/pr110790-2.c > scan- > > assembler-times shrq 2 on Linux/x86_64 > > > > > -----Original Message----- > > > From: Andrew Pinski (QUIC) <[email protected]> > > > Sent: Tuesday, December 12, 2023 9:01 AM > > > To: haochen.jiang <[email protected]>; Andrew Pinski (QUIC) > > > <[email protected]>; [email protected]; gcc- > > > [email protected]; Jiang, Haochen <[email protected]> > > > Subject: RE: [r14-6420 Regression] FAIL: gcc.target/i386/pr110790-2.c > > scan- > > > assembler-times shrq 2 on Linux/x86_64 > > > > > > > -----Original Message----- > > > > From: haochen.jiang <[email protected]> > > > > Sent: Monday, December 11, 2023 4:54 PM > > > > To: Andrew Pinski (QUIC) <[email protected]>; gcc- > > > > [email protected]; [email protected]; > > [email protected] > > > > Subject: [r14-6420 Regression] FAIL: gcc.target/i386/pr110790-2.c > scan- > > > > assembler-times shrq 2 on Linux/x86_64 > > > > > > > > On Linux/x86_64, > > > > > > > > 85c5efcffed19ca6160eeecc2d4faebd9fee63aa is the first bad commit > > commit > > > > 85c5efcffed19ca6160eeecc2d4faebd9fee63aa > > > > Author: Andrew Pinski <[email protected]> > > > > Date: Sat Nov 11 15:54:10 2023 -0800 > > > > > > > > MATCH: (convert)(zero_one !=/== 0/1) for outer type and zero_one > type > > are > > > > the same > > > > > > > > caused > > > > > > > > FAIL: gcc.target/i386/pr110790-2.c scan-assembler-times shrq 2 > > > > > > > > > So I think this is a testsuite issue, in that shrx instruction is > being used here > > > instead of just ` shrq` due to that instruction being enabled with `- > > > march=cascadelake` . > > > Can someone confirm that and submit a testcase change? > > > > I will do that today. > > I suppose we might just need to change the scan-asm from shrq to shr to > cover > shrx. > > Is that ok? If it is, I will commit a patch to change that. > >From my point of view, that would be the correct approach but I cannot approve it. Thanks, Andrew > Thx, > Haochen > > > > > Thx, > > Haochen > > > > > > > > Thanks, > > > Andrew > > > > > > > > > > > with GCC configured with > > > > > > > > ../../gcc/configure --prefix=/export/users/haochenj/src/gcc- > > > > bisect/master/master/r14-6420/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/pr110790-2.c -- > > > > target_board='unix{-m64\ -march=cascadelake}'" > > > > > > > > (Please do not reply to this email, for question about this report, > contact > > me at > > > > haochen dot jiang at intel.com.) (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.) >
