Re: Regressions for gcc.c-torture/compile/961203-1.c gcc.dg/20020219-1.c on 64-x-32 with PR32563 sign/sizetype fix

[Richard Guenther <rguenther at suse dot de>]

On Thu, 23 Aug 2007, Hans-Peter Nilsson wrote:

> > Date: Tue, 21 Aug 2007 13:59:16 +0200 (CEST)
> > From: Richard Guenther <rguenther@suse.de>
> 
> > 	PR middle-end/32563
> > 	* tree.c (host_integerp): Treat sizetype as signed as it is
> > 	sign-extended.
> 
> > Index: tree.c
> > ===================================================================
> > *** tree.c	(revision 127658)
> > --- tree.c	(working copy)
> > *************** host_integerp (const_tree t, int pos)
> > *** 4936,4942 ****
> >   	       && (HOST_WIDE_INT) TREE_INT_CST_LOW (t) >= 0)
> >   	      || (! pos && TREE_INT_CST_HIGH (t) == -1
> >   		  && (HOST_WIDE_INT) TREE_INT_CST_LOW (t) < 0
> > ! 		  && !TYPE_UNSIGNED (TREE_TYPE (t)))
> >   	      || (pos && TREE_INT_CST_HIGH (t) == 0)));
> >   }
> >   
> > --- 4936,4943 ----
> >   	       && (HOST_WIDE_INT) TREE_INT_CST_LOW (t) >= 0)
> >   	      || (! pos && TREE_INT_CST_HIGH (t) == -1
> >   		  && (HOST_WIDE_INT) TREE_INT_CST_LOW (t) < 0
> > ! 		  && (!TYPE_UNSIGNED (TREE_TYPE (t))
> > ! 		      || TYPE_IS_SIZETYPE (TREE_TYPE (t))))
> >   	      || (pos && TREE_INT_CST_HIGH (t) == 0)));
> >   }
> 
> This patch (r127688) caused these regressions for cris-elf, when
> hosted on amd64:
> 
> Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
> FAIL: gcc.c-torture/compile/961203-1.c  -O2  (internal compiler error)
> FAIL: gcc.c-torture/compile/961203-1.c  -O2  (test for excess errors)
> FAIL: gcc.c-torture/compile/961203-1.c  -O3 -fomit-frame-pointer  (internal compiler error)
> FAIL: gcc.c-torture/compile/961203-1.c  -O3 -fomit-frame-pointer  (test for excess errors)
> FAIL: gcc.c-torture/compile/961203-1.c  -O3 -g  (internal compiler error)
> FAIL: gcc.c-torture/compile/961203-1.c  -O3 -g  (test for excess errors)
> FAIL: gcc.c-torture/compile/961203-1.c  -Os  (internal compiler error)
> FAIL: gcc.c-torture/compile/961203-1.c  -Os  (test for excess errors)
> ...
> Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/dg.exp ...
> FAIL: gcc.dg/20020219-1.c execution test
> 
> With this in gcc.log:
> Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/   -O2  -w -fno-show-column -c   -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include  -o 961203-1.o /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/compile/961203-1.c    (timeout = 300)
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/compile/961203-1.c: In function 'main':
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/compile/961203-1.c:19: error: unrecognizable insn:
> (insn 6 5 7 3 /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/compile/961203-1.c:17 (set (reg:SI 30)
>         (const_int 2305843008979861504 [0x1ffffffff2100000])) -1 (nil))
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.c-torture/compile/961203-1.c:19: internal compiler error: in extract_insn, at recog.c:1990
> 
> and:
> 
> core: 4 byte read to unmapped address 0xe00010d4 at 0x144
> program stopped with signal 11.
> FAIL: gcc.dg/20020219-1.c execution test
> 
> Perhaps an exposed bug; a host_integerp where there should have
> been a target_integerp somewhere (well, you know what I mean)...

The difference starts after expansion where we have for example
(working vs. non-working)

-(insn 6 5 7 
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.c-torture/compile/961203-1.c:17 
(set (reg/f:SI 29)
+(insn 6 5 7 
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.c-torture/compile/961203-1.c:17 
(set (reg:SI 30)
+        (const_int 2305843008979861504 [0x1ffffffff2100000])) -1 (nil))
+
+(insn 7 6 8 
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.c-torture/compile/961203-1.c:17 
(set (reg/f:SI 29)
         (plus:SI (reg/f:SI 28)
-            (const_int 839909376 [0x32100000]))) -1 (nil))
+            (reg:SI 30))) -1 (nil))

the interesting thing is that for the 0->x COMPONENT_REF the
component_ref_field_offset is 839909376.  When in get_inner_reference
we multiply that by bitsize_unit_node (8) we get

 <integer_cst 0x2b79ae711b40 type <integer_type 0x2b79add7f0d0 
bit_size_type> constant invariant public overflow -1870659584>

(an overflowed CST that is, which happens to be still host_integerp).

So, can you test (the execution failures) the following for me on
cris-elf?

Thanks,
Richard.

Index: expr.c
===================================================================
--- expr.c	(revision 127731)
+++ expr.c	(working copy)
@@ -5915,6 +5915,7 @@ get_inner_reference (tree exp, HOST_WIDE
 				 fold_convert (bitsizetype, offset),
 				 bitsize_unit_node))
       && 0 != (tem = size_binop (PLUS_EXPR, tem, bit_offset))
+      && !TREE_OVERFLOW (tem)
       && host_integerp (tem, 0))
     *pbitpos = tree_low_cst (tem, 0), *poffset = 0;
   else