On 11/19/20 10:56 PM, sunil.k.pandey wrote:
On Linux/x86_64,

d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9 is the first bad commit
commit d0d8b5d83614d8f0d0e40c0520d4f40ffa01f8d9
Author: Andrew MacLeod <amacl...@redhat.com>
Date:   Thu Nov 19 17:41:30 2020 -0500

     Process only valid shift ranges.

caused

FAIL: gcc.dg/pr97515.c scan-tree-dump-times evrp "goto" 1

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-5185/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="dg.exp=gcc.dg/pr97515.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr97515.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr97515.c 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check RUNTESTFLAGS="dg.exp=gcc.dg/pr97515.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

huh, that slipped by on my regressions run...  obfuscated by all the various "tree-prof" unresolved errors that always seem to be happening.

Anyway.

so the problem here appears to be that when we had
  [-1,-1] >> VARYING
This use to overflow in the cross product code and just return VARYING.
now that its being masked to
 [-1,-1] >> [0,31]

so in the end, the rshift cross product code decides the result is [-1, -1]  instead of varying.

THis ends up changing the calculations, and we realized certain other parts of the program are unreachable sooner, and the undefined value is cant be usied in constant propagation, so we dont fold away a couple of phis..
..

I added a comment to describing why this is happening and adjusted the testcase for now to check in CCP that everything folded away.

pushed an adjustment to the testcase to check in CCP2 for now that everything folded away.

Andrew






commit 65854626304d50cf348af53de1c29ccec06d33c6
Author: Andrew MacLeod <amacl...@redhat.com>
Date:   Fri Nov 20 10:37:26 2020 -0500

    re: FAIL: gcc.dg/pr97515.c
    
    Adjust testcase to check in CCP not EVRP.
    
            gcc/testuite/
            * gcc.dg/pr97515.c: Check in ccp2, not evrp.

diff --git a/gcc/testsuite/gcc.dg/pr97515.c b/gcc/testsuite/gcc.dg/pr97515.c
index 84f145a261f..b4f2481cb03 100644
--- a/gcc/testsuite/gcc.dg/pr97515.c
+++ b/gcc/testsuite/gcc.dg/pr97515.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-evrp" } */
+/* { dg-options "-O2 -fdump-tree-ccp2" } */
 
 int
 e7 (int gg)
@@ -20,6 +20,8 @@ e7 (int gg)
   return xe;
 }
 
-/* EVRP should be able to reduce this to a single goto.  */
+/* EVRP should be able to reduce this to a single goto when we can
+ * revisit statements to try folding again based on changed inputs.
+ * Until then, make sure its gone by ccp2.  */
  
-/* { dg-final { scan-tree-dump-times "goto" 1 "evrp" } } */
+/* { dg-final { scan-tree-dump-times "goto" 1 "ccp2" } } */

Reply via email to