Re: Q about Ada and value ranges in types

Re: Q about Ada and value ranges in types

[Richard Kenner]

    RTH has been suggesting to use build_int_cst (etype, 0) instead.

Indeed.  I was trying to minimize the change, but such cleanups are always
useful.  This was also missing a protection on INTEGER_TYPE_P.  I just got
a good bootstrap of Ada on x86_64 with this and a patch from Diego to fix
the other problem and also remove the kludge that's fixed by this.

Re: Q about Ada and value ranges in types

[James A. Morrison]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> Sorry it took me so long to get to this.
> 
>     > You're not showing where this comes from, so it's hard to say.  However
>     > D.1480 is created by the gimplifier, not the Ada front end.  There could
>     > easily be a typing problem in the tree there (e.g., that of the
>     > subtraction) but I can't tell for sure.
> 
> As it turned out, there was.
> 
>     So, after calling sinfo__chars() and subtracting 300000361, the
>     FE is emitting that range check.  AFAICT, the call to
>     sinfo__chars(e_5) comes from ada/sem_intr.adb:148
> 
> 	     Nam : constant Name_Id   := Chars (E);
> 
>     and 'if (D.1480_32 <= 1)' is at line 155:
> 
> I'd also assumed this was where the bogus tree came from, but I was wrong.
> The node in question was not made by the Ada front end but by
> build_range_check in clearly incorrect code that does the subtraction in the
> wrong type.
> 
> This fixes that problem.  Are you in a position to check if it fixes the
> original issue?
> 
> *** fold-const.c	25 Jun 2005 01:59:57 -0000	1.599
> --- fold-const.c	27 Jun 2005 20:44:56 -0000
> *************** build_range_check (tree type, tree exp, 
> *** 4027,4034 ****
>   
>     if (value != 0 && ! TREE_OVERFLOW (value))
> !     return build_range_check (type,
> ! 			      fold_build2 (MINUS_EXPR, etype, exp, low),
> ! 			      1, fold_convert (etype, integer_zero_node),
> ! 			      value);
>   
>     return 0;
> --- 4027,4045 ----
>   
>     if (value != 0 && ! TREE_OVERFLOW (value))
> !     {
> !       /* There is no requirement that LOW be within the range of ETYPE
> ! 	 if the latter is a subtype.  It must, however, be within the base
> ! 	 type of ETYPE.  So be sure we do the subtraction in that type.  */
> !       if (TREE_TYPE (etype))
> ! 	{
> ! 	  etype = TREE_TYPE (etype);
> ! 	  value = fold_convert (etype, value);
> ! 	}
> ! 
> !       return build_range_check (type,
> ! 				fold_build2 (MINUS_EXPR, etype, exp, low),
> ! 				1, fold_convert (etype, integer_zero_node),
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 RTH has been suggesting to use build_int_cst (etype, 0) instead.

> ! 				value);
> !     }
>   
>     return 0;
> 


-- 
Thanks,
Jim

http://www.csclub.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim

Re: Q about Ada and value ranges in types

[Richard Kenner]

Sorry it took me so long to get to this.

    > You're not showing where this comes from, so it's hard to say.  However
    > D.1480 is created by the gimplifier, not the Ada front end.  There could
    > easily be a typing problem in the tree there (e.g., that of the
    > subtraction) but I can't tell for sure.

As it turned out, there was.

    So, after calling sinfo__chars() and subtracting 300000361, the
    FE is emitting that range check.  AFAICT, the call to
    sinfo__chars(e_5) comes from ada/sem_intr.adb:148

	     Nam : constant Name_Id   := Chars (E);

    and 'if (D.1480_32 <= 1)' is at line 155:

I'd also assumed this was where the bogus tree came from, but I was wrong.
The node in question was not made by the Ada front end but by
build_range_check in clearly incorrect code that does the subtraction in the
wrong type.

This fixes that problem.  Are you in a position to check if it fixes the
original issue?

*** fold-const.c	25 Jun 2005 01:59:57 -0000	1.599
--- fold-const.c	27 Jun 2005 20:44:56 -0000
*************** build_range_check (tree type, tree exp, 
*** 4027,4034 ****
  
    if (value != 0 && ! TREE_OVERFLOW (value))
!     return build_range_check (type,
! 			      fold_build2 (MINUS_EXPR, etype, exp, low),
! 			      1, fold_convert (etype, integer_zero_node),
! 			      value);
  
    return 0;
--- 4027,4045 ----
  
    if (value != 0 && ! TREE_OVERFLOW (value))
!     {
!       /* There is no requirement that LOW be within the range of ETYPE
! 	 if the latter is a subtype.  It must, however, be within the base
! 	 type of ETYPE.  So be sure we do the subtraction in that type.  */
!       if (TREE_TYPE (etype))
! 	{
! 	  etype = TREE_TYPE (etype);
! 	  value = fold_convert (etype, value);
! 	}
! 
!       return build_range_check (type,
! 				fold_build2 (MINUS_EXPR, etype, exp, low),
! 				1, fold_convert (etype, integer_zero_node),
! 				value);
!     }
  
    return 0;

Re: Q about Ada and value ranges in types

[Diego Novillo]

On Tue, May 03, 2005 at 06:21:11PM -0400, Richard Kenner wrote:

> As of right now, I don't think this is a VRP problem, but something wrong
> with the tree Ada produces.
> 
That'd be good.  If that's the case, we can make VRP assert that
the range derived from such types agrees with the type's range.



Thanks.  Diego.

Re: Q about Ada and value ranges in types

[Richard Kenner]

     Yeah, I didn't show all of it, sorry.  My patch to address this
     problem includes a more detailed description
     (http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html).

As of right now, I don't think this is a VRP problem, but something wrong
with the tree Ada produces.

     Configure a compiler for target i386-pc-linux-gnu (or any other
     i386 variant, not sure if it occurs elsewhere) and compile
     ada/sem_intr.adb with:

I'm out of town until tomorrow and will do this then.

Re: Q about Ada and value ranges in types

[Diego Novillo]

On Mon, May 02, 2005 at 09:46:59PM -0400, Richard Kenner wrote:

> You're not showing where this comes from, so it's hard to say.  However
> D.1480 is created by the gimplifier, not the Ada front end.  There could
> easily be a typing problem in the tree there (e.g., that of the subtraction),
> but I can't tell for sure.
> 
Yeah, I didn't show all of it, sorry.  My patch to address this
problem includes a more detailed description
(http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html).

Florian Weimer suggested that instead of marking the range as
varying, we could check the super-type to see if it has a wider
range.  That is true in this case; the parent type is
types__Tname_idB which has range [-2147483648, 2147483647].  But
I'm not sure if that would be true in general.

>     If the Ada language allows that kind of runtime check, then my
>     fix to VRP will be different. 
> 
> I don't see it as a language issue: I'd argue that the tree in statement 2
> is invalid given the typing.  That should be true for any language.
> 
Dunno.  All the operands in the snippet I showed are of the exact
same type (types__name_id___XDLU_300000000__399999999).  I'm not
really sure where this type is coming from, but it's relatively
easy to reproduce.

Configure a compiler for target i386-pc-linux-gnu (or any other
i386 variant, not sure if it occurs elsewhere) and compile
ada/sem_intr.adb with:

$ ./xgcc -B./ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I<src>/gcc/ada <src>/gcc/ada/sem_intr.adb -o ada/sem_intr.o -v -save-temps

Launch gdb and set a bkpt at tree-vrp.c:552 (extract_range_from_assert).
You should get to this ASSERT_EXPR:

ASSERT_EXPR <D.1480_32, D.1480_32 <= 1>

which is in the following context:

-----------------------------------------------------------------------------
;; basic block 44, loop depth 0, count 0
;; prev block 43, next block 84
;; pred:       43 (true,exec)
;; succ:       84 (true,exec) 45 (false,exec)
<L51>:;
D.1478_28 = sinfo__etype (e_5);
nam_30 = sinfo__chars (e_5);
D.1480_32 = nam_30 - 300000361;
if (D.1480_32 <= 1) goto <L112>; else goto <L52>;

;; basic block 84, loop depth 0, count 0
;; prev block 44, next block 45
;; pred:       44 (true,exec)
;; succ:       50 [100.0%]  (fallthru)
<L112>:;
D.1480_94 = ASSERT_EXPR <D.1480_32, D.1480_32 <= 1>;
goto <bb 50> (<L57>);
-----------------------------------------------------------------------------

So, after calling sinfo__chars() and subtracting 300000361, the
FE is emitting that range check.  AFAICT, the call to
sinfo__chars(e_5) comes from ada/sem_intr.adb:148

	     Nam : constant Name_Id   := Chars (E);

and 'if (D.1480_32 <= 1)' is at line 155:
     
     	     if Nam = Name_Op_Add


Thanks.  Diego.

Re: Q about Ada and value ranges in types

[Richard Kenner]

    I am tracking an ICE in VRP that triggers only in Ada.  Given
    this:

     1	D.1480_32 = nam_30 - 300000361;
     2	if (D.1480_32 <= 1) goto <L112>; else goto <L52>;
     3	<L112>:;
     4	D.1480_94 = ASSERT_EXPR <D.1480_32, D.1480_32 <= 1>;
     5	goto <bb 50> (<L57>);

    for name D.1480_94.  However, the type of D.1480 is:

    (gdb) ptu type
     const types__name_id___XDLU_300000000__399999999

     <integer_type 0xf6f3f360 types__name_id___XDLU_300000000__399999999
        type <integer_type 0xf6f3cec4 types__Tname_idB sizes-gimplified visited
    [ ... ]
         min <integer_cst 0xf6f40060 300000000>
        max <integer_cst 0xf6f40090 399999999>
         RM size <integer_cst 0xf6ee13f0 32>>

    My question is, is Ada emitting an always-false predicate in line
    #2?  Or is it a bug?

You're not showing where this comes from, so it's hard to say.  However
D.1480 is created by the gimplifier, not the Ada front end.  There could
easily be a typing problem in the tree there (e.g., that of the subtraction),
but I can't tell for sure.

    If the Ada language allows that kind of runtime check, then my
    fix to VRP will be different. 

I don't see it as a language issue: I'd argue that the tree in statement 2
is invalid given the typing.  That should be true for any language.

(Note that there's a system problem and email to this address won't be
received until tomorrow afternoon.)

Q about Ada and value ranges in types

[Diego Novillo]

I am tracking an ICE in VRP that triggers only in Ada.  Given
this:

     1	D.1480_32 = nam_30 - 300000361;
     2	if (D.1480_32 <= 1) goto <L112>; else goto <L52>;
     3	<L112>:;
     4	D.1480_94 = ASSERT_EXPR <D.1480_32, D.1480_32 <= 1>;
     5	goto <bb 50> (<L57>);


When visiting statemen #4, VRP tries to create the range [-INF, 1] 
for name D.1480_94.  However, the type of D.1480 is:

(gdb) ptu type
const types__name_id___XDLU_300000000__399999999

 <integer_type 0xf6f3f360 types__name_id___XDLU_300000000__399999999
    type <integer_type 0xf6f3cec4 types__Tname_idB sizes-gimplified visited SI
[ ... ]
    min <integer_cst 0xf6f40060 300000000>
    max <integer_cst 0xf6f40090 399999999>
     RM size <integer_cst 0xf6ee13f0 32>>


So, for this type -INF is 300000000, and thus the range that we
try to create is [300000000, 1] which is invalid.

My question is, is Ada emitting an always-false predicate in line
#2?  Or is it a bug?  What would happen if nam_30 (also of the
same type) was 300000000?

If the Ada language allows that kind of runtime check, then my
fix to VRP will be different.  On examining 'D.1480_32 = name_30
- 300000361' we could create the range [300000000, 399999999] for
D.1480_32 and fold statement #2 directly.


Thanks.  Diego.