Re: fix for execute/991221-1.c -O1 failure

Re: fix for execute/991221-1.c -O1 failure

[Joern Rennecke]

> *************** range_binop (code, type, arg0, upper0_p,
> *** 3180,3187 ****
>        We can therefore make the transformation of any unbounded range with
>        the value Z, Z being greater than any representable number. This permits
>        us to treat unbounded ranges as equal. */
> !   sgn0 = arg0 != 0 ? 0 : (upper0_p ? 1 : -1);
> !   sgn1 = arg1 != 0 ? 0 : (upper1_p ? 1 : -1);
>     switch (code)
>       {
>       case EQ_EXPR:
> --- 3180,3199 ----
>        We can therefore make the transformation of any unbounded range with
>        the value Z, Z being greater than any representable number. This permits
>        us to treat unbounded ranges as equal. */
> !   sgn0 = (upper0_p
> ! 	  ? ((! arg0
> ! 	      || operand_equal_p (arg0, TYPE_MAX_VALUE (TREE_TYPE (arg0)), 1))
> ! 	     ? 1 : 0)
> ! 	  : ((! arg0
> ! 	      || operand_equal_p (arg0, TYPE_MIN_VALUE (TREE_TYPE (arg0)), 1))
> ! 	     ? -1 : 0));
> !   sgn1 = (upper1_p
> ! 	  ? ((! arg1
> ! 	      || operand_equal_p (arg1, TYPE_MAX_VALUE (TREE_TYPE (arg1)), 1))
> ! 	     ? 1 : 0)
> ! 	  : ((! arg1
> ! 	      || operand_equal_p (arg1, TYPE_MIN_VALUE (TREE_TYPE (arg1)), 1))
> ! 	     ? -1 : 0));
>     switch (code)
>       {
>       case EQ_EXPR:

Hmmm, I forgot to re-generate the patch after I fixed this to actually use
TYPE.

Bu I have a different problem here: the bootstrap fails when compiling reload.
It encounters a pointer_type, and this has no min nor max value.

(gdb) call debug_tree(type)
 <pointer_type 0x4028c280
    type <integer_type 0x4001a300 short int
        permanent HI
        size <integer_cst 0x40019320 constant permanent 16>
        align 16 symtab 8 alias set 24 precision 16
        min <integer_cst 0x400194a0 constant permanent -32768>
        max <integer_cst 0x400194c0 constant permanent 32767>
        pointer_to_this <pointer_type 0x4028c280>>
   
    unsigned permanent SI
    size <integer_cst 0x40019560 type <integer_type 0x4001b580 unsigned int> constant permanent 32>
    align 32 symtab 352 alias set 93>

Should I get the limits from somewhere else?  Or should pointers be treated as
having indeed no bounds?

*************** range_binop (code, type, arg0, upper0_p,
*** 3180,3187 ****
       We can therefore make the transformation of any unbounded range with
       the value Z, Z being greater than any representable number. This permits
       us to treat unbounded ranges as equal. */
!   sgn0 = arg0 != 0 ? 0 : (upper0_p ? 1 : -1);
!   sgn1 = arg1 != 0 ? 0 : (upper1_p ? 1 : -1);
    switch (code)
      {
      case EQ_EXPR:
--- 3180,3195 ----
       We can therefore make the transformation of any unbounded range with
       the value Z, Z being greater than any representable number. This permits
       us to treat unbounded ranges as equal. */
!   sgn0 = (upper0_p
! 	  ? (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
! 	     ? 1 : 0)
! 	  : (! arg0 || operand_equal_p (arg0, TYPE_MIN_VALUE (type), 1)
! 	     ? -1 : 0));
!   sgn1 = (upper1_p
! 	  ? (! arg1 || operand_equal_p (arg1, TYPE_MAX_VALUE (type), 1)
! 	     ? 1 : 0)
! 	  : (! arg1 || operand_equal_p (arg1, TYPE_MIN_VALUE (type), 1)
! 	     ? -1 : 0));
    switch (code)
      {
      case EQ_EXPR:

Re: fix for execute/991221-1.c -O1 failure

[Jeffrey A Law]

  In message < 199912240645.GAA16571@phal.cygnus.co.uk >you write:
  > Hmmm, I forgot to re-generate the patch after I fixed this to actually
  > use TYPE.
  > 
  > But I have a different problem here: the bootstrap fails when compiling
  > reload.  It encounters a pointer_type, and this has no min nor max value.
  > 
  > (gdb) call debug_tree(type)
  >  <pointer_type 0x4028c280
  >     type <integer_type 0x4001a300 short int
  >         permanent HI
  >         size <integer_cst 0x40019320 constant permanent 16>
  >         align 16 symtab 8 alias set 24 precision 16
  >         min <integer_cst 0x400194a0 constant permanent -32768>
  >         max <integer_cst 0x400194c0 constant permanent 32767>
  >         pointer_to_this <pointer_type 0x4028c280>>
  >    
  >     unsigned permanent SI
  >     size <integer_cst 0x40019560 type <integer_type 0x4001b580 unsigned int
  > > constant permanent 32>
  >     align 32 symtab 352 alias set 93>
  > 
  > Should I get the limits from somewhere else?  Or should pointers be
  > treated as having indeed no bounds?
Treating the pointer type as having no bounds is certainly a safe thing to
do.  Finding the range of a pointer type is somewhat complicated by the
signed vs unsigned issues.


Note instead of:

!   sgn0 = (upper0_p
! 	  ? (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
! 	     ? 1 : 0)
! 	  : (! arg0 || operand_equal_p (arg0, TYPE_MIN_VALUE (type), 1)
! 	     ? -1 : 0));


It might be better to write

   sgn0 = (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
           ? (upper0_p ? 1 : -1) : 0);

Similarly for the other instances of similar code.  

jeff

Re: fix for execute/991221-1.c -O1 failure

[Joern Rennecke]

>   > Should I get the limits from somewhere else?  Or should pointers be
>   > treated as having indeed no bounds?
> Treating the pointer type as having no bounds is certainly a safe thing to
> do.  Finding the range of a pointer type is somewhat complicated by the
> signed vs unsigned issues.

Well, treating it as having no bounds also requires some special handling,
since otherwise we would keep the original bug for unsigned pointers.

> Note instead of:
> 
> !   sgn0 = (upper0_p
> ! 	  ? (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
> ! 	     ? 1 : 0)
> ! 	  : (! arg0 || operand_equal_p (arg0, TYPE_MIN_VALUE (type), 1)
> ! 	     ? -1 : 0));
> 
> 
> It might be better to write
> 
>    sgn0 = (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
>            ? (upper0_p ? 1 : -1) : 0);

Note that there are two different macro calls, one for the minimum
and one for the maximum.

Re: fix for execute/991221-1.c -O1 failure

[Joern Rennecke]

Here is the pointerized version of 991221.c .
I know this is not standard C, but I suppose gcc should be able to handle
this.  N.B. it works with -O0 but fails when optimizing.

gcc itself uses -1 as a special 'pointer' value in some places.

int main( void )
{
   char *totalsize = (char *)80;
   char *msize = (char *)64;

   if (sizeof(char *) != 4)
     exit(0);
   
   if ( totalsize > (char *)(2147483647L   * 2UL + 1)  
        || (msize != 0 && ((msize - 1) > (char *)(2147483647L   * 2UL + 1) )))
      abort();
   exit( 0 );
}

Re: fix for execute/991221-1.c -O1 failure

[Martin v. Loewis]

> Here is the pointerized version of 991221.c .
> I know this is not standard C, but I suppose gcc should be able to handle
> this.  N.B. it works with -O0 but fails when optimizing.
> 
> gcc itself uses -1 as a special 'pointer' value in some places.

I agree this test should pass. I'm not so sure that gcc should perform
the range folding. Couldn't it just avoid the folding if the arguments
in the relative operator are pointer literals?

Regards,
Martin

Re: fix for execute/991221-1.c -O1 failure

[Jeffrey A Law]

  In message < 199912240645.GAA16571@phal.cygnus.co.uk >you write:
  > Hmmm, I forgot to re-generate the patch after I fixed this to actually
  > use TYPE.
  > 
  > But I have a different problem here: the bootstrap fails when compiling
  > reload.  It encounters a pointer_type, and this has no min nor max value.
  > 
  > (gdb) call debug_tree(type)
  >  <pointer_type 0x4028c280
  >     type <integer_type 0x4001a300 short int
  >         permanent HI
  >         size <integer_cst 0x40019320 constant permanent 16>
  >         align 16 symtab 8 alias set 24 precision 16
  >         min <integer_cst 0x400194a0 constant permanent -32768>
  >         max <integer_cst 0x400194c0 constant permanent 32767>
  >         pointer_to_this <pointer_type 0x4028c280>>
  >    
  >     unsigned permanent SI
  >     size <integer_cst 0x40019560 type <integer_type 0x4001b580 unsigned int
  > > constant permanent 32>
  >     align 32 symtab 352 alias set 93>
  > 
  > Should I get the limits from somewhere else?  Or should pointers be
  > treated as having indeed no bounds?
Treating the pointer type as having no bounds is certainly a safe thing to
do.  Finding the range of a pointer type is somewhat complicated by the
signed vs unsigned issues.


Note instead of:

!   sgn0 = (upper0_p
! 	  ? (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
! 	     ? 1 : 0)
! 	  : (! arg0 || operand_equal_p (arg0, TYPE_MIN_VALUE (type), 1)
! 	     ? -1 : 0));


It might be better to write

   sgn0 = (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
           ? (upper0_p ? 1 : -1) : 0);

Similarly for the other instances of similar code.  

jeff

Re: fix for execute/991221-1.c -O1 failure

[Joern Rennecke]

Here is the pointerized version of 991221.c .
I know this is not standard C, but I suppose gcc should be able to handle
this.  N.B. it works with -O0 but fails when optimizing.

gcc itself uses -1 as a special 'pointer' value in some places.

int main( void )
{
   char *totalsize = (char *)80;
   char *msize = (char *)64;

   if (sizeof(char *) != 4)
     exit(0);
   
   if ( totalsize > (char *)(2147483647L   * 2UL + 1)  
        || (msize != 0 && ((msize - 1) > (char *)(2147483647L   * 2UL + 1) )))
      abort();
   exit( 0 );
}

Re: fix for execute/991221-1.c -O1 failure

[Martin v. Loewis]

> Here is the pointerized version of 991221.c .
> I know this is not standard C, but I suppose gcc should be able to handle
> this.  N.B. it works with -O0 but fails when optimizing.
> 
> gcc itself uses -1 as a special 'pointer' value in some places.

I agree this test should pass. I'm not so sure that gcc should perform
the range folding. Couldn't it just avoid the folding if the arguments
in the relative operator are pointer literals?

Regards,
Martin

Re: fix for execute/991221-1.c -O1 failure

[Joern Rennecke]

> *************** range_binop (code, type, arg0, upper0_p,
> *** 3180,3187 ****
>        We can therefore make the transformation of any unbounded range with
>        the value Z, Z being greater than any representable number. This permits
>        us to treat unbounded ranges as equal. */
> !   sgn0 = arg0 != 0 ? 0 : (upper0_p ? 1 : -1);
> !   sgn1 = arg1 != 0 ? 0 : (upper1_p ? 1 : -1);
>     switch (code)
>       {
>       case EQ_EXPR:
> --- 3180,3199 ----
>        We can therefore make the transformation of any unbounded range with
>        the value Z, Z being greater than any representable number. This permits
>        us to treat unbounded ranges as equal. */
> !   sgn0 = (upper0_p
> ! 	  ? ((! arg0
> ! 	      || operand_equal_p (arg0, TYPE_MAX_VALUE (TREE_TYPE (arg0)), 1))
> ! 	     ? 1 : 0)
> ! 	  : ((! arg0
> ! 	      || operand_equal_p (arg0, TYPE_MIN_VALUE (TREE_TYPE (arg0)), 1))
> ! 	     ? -1 : 0));
> !   sgn1 = (upper1_p
> ! 	  ? ((! arg1
> ! 	      || operand_equal_p (arg1, TYPE_MAX_VALUE (TREE_TYPE (arg1)), 1))
> ! 	     ? 1 : 0)
> ! 	  : ((! arg1
> ! 	      || operand_equal_p (arg1, TYPE_MIN_VALUE (TREE_TYPE (arg1)), 1))
> ! 	     ? -1 : 0));
>     switch (code)
>       {
>       case EQ_EXPR:

Hmmm, I forgot to re-generate the patch after I fixed this to actually use
TYPE.

Bu I have a different problem here: the bootstrap fails when compiling reload.
It encounters a pointer_type, and this has no min nor max value.

(gdb) call debug_tree(type)
 <pointer_type 0x4028c280
    type <integer_type 0x4001a300 short int
        permanent HI
        size <integer_cst 0x40019320 constant permanent 16>
        align 16 symtab 8 alias set 24 precision 16
        min <integer_cst 0x400194a0 constant permanent -32768>
        max <integer_cst 0x400194c0 constant permanent 32767>
        pointer_to_this <pointer_type 0x4028c280>>
   
    unsigned permanent SI
    size <integer_cst 0x40019560 type <integer_type 0x4001b580 unsigned int> constant permanent 32>
    align 32 symtab 352 alias set 93>

Should I get the limits from somewhere else?  Or should pointers be treated as
having indeed no bounds?

*************** range_binop (code, type, arg0, upper0_p,
*** 3180,3187 ****
       We can therefore make the transformation of any unbounded range with
       the value Z, Z being greater than any representable number. This permits
       us to treat unbounded ranges as equal. */
!   sgn0 = arg0 != 0 ? 0 : (upper0_p ? 1 : -1);
!   sgn1 = arg1 != 0 ? 0 : (upper1_p ? 1 : -1);
    switch (code)
      {
      case EQ_EXPR:
--- 3180,3195 ----
       We can therefore make the transformation of any unbounded range with
       the value Z, Z being greater than any representable number. This permits
       us to treat unbounded ranges as equal. */
!   sgn0 = (upper0_p
! 	  ? (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
! 	     ? 1 : 0)
! 	  : (! arg0 || operand_equal_p (arg0, TYPE_MIN_VALUE (type), 1)
! 	     ? -1 : 0));
!   sgn1 = (upper1_p
! 	  ? (! arg1 || operand_equal_p (arg1, TYPE_MAX_VALUE (type), 1)
! 	     ? 1 : 0)
! 	  : (! arg1 || operand_equal_p (arg1, TYPE_MIN_VALUE (type), 1)
! 	     ? -1 : 0));
    switch (code)
      {
      case EQ_EXPR:

Re: fix for execute/991221-1.c -O1 failure

[Joern Rennecke]

>   > Should I get the limits from somewhere else?  Or should pointers be
>   > treated as having indeed no bounds?
> Treating the pointer type as having no bounds is certainly a safe thing to
> do.  Finding the range of a pointer type is somewhat complicated by the
> signed vs unsigned issues.

Well, treating it as having no bounds also requires some special handling,
since otherwise we would keep the original bug for unsigned pointers.

> Note instead of:
> 
> !   sgn0 = (upper0_p
> ! 	  ? (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
> ! 	     ? 1 : 0)
> ! 	  : (! arg0 || operand_equal_p (arg0, TYPE_MIN_VALUE (type), 1)
> ! 	     ? -1 : 0));
> 
> 
> It might be better to write
> 
>    sgn0 = (! arg0 || operand_equal_p (arg0, TYPE_MAX_VALUE (type), 1)
>            ? (upper0_p ? 1 : -1) : 0);

Note that there are two different macro calls, one for the minimum
and one for the maximum.

Re: fix for execute/991221-1.c -O1 failure

[Jeffrey A Law]

  In message <199912302119.WAA22451@loewis.home.cs.tu-berlin.de>you write:
  > > Here is the pointerized version of 991221.c .
  > > I know this is not standard C, but I suppose gcc should be able to handle
  > > this.  N.B. it works with -O0 but fails when optimizing.
  > > 
  > > gcc itself uses -1 as a special 'pointer' value in some places.
  > 
  > I agree this test should pass. I'm not so sure that gcc should perform
  > the range folding. Couldn't it just avoid the folding if the arguments
  > in the relative operator are pointer literals?
Probably since we're working at the tree level.  Presumably we can always
get to the type.

I'd be leery of trying to do any kind of range optimizations on pointer
types.  Especially since we have targets where we can have multiple bit
representations which reference the same object (function pointers for
PA32 runtime model for example).

jeff

Re: fix for execute/991221-1.c -O1 failure

[Joern Rennecke]

> I'd be leery of trying to do any kind of range optimizations on pointer
> types.  Especially since we have targets where we can have multiple bit
> representations which reference the same object (function pointers for
> PA32 runtime model for example).

Well, we do now, but incorrectly.  My patches aim to make the optimizations
correct.
I'm not sure that trying to disable the pointer optimization will be any
simpler or safer.