Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

     No, the language (or, more precisely, GNAT) defines them as 0 and
     2**size - 1.  Otherwise the 'Valid attribute doesn't work.  Necessary
     range checks will be optimized away, too.

No, enumeration types are defined as having precisely the set of
values specifically listed.  In the presence of rep clauses, these may
not even be a contiguous set.

The language doesn't define the concept of a "base type" for enumeration
types, but I think Gigi has to pretend there is such a thing and make
it the full range of the underlying precision.  That would make the
enumeration type a subtype.  The problem is that I think there's code
in the middle-end that assumes that all subtypes are INTEGER_TYPE, so
there's a real mess here about what should be done.

But there's no question that the type directly corresponding to the
Ada type needs the proper bounds: the issue is that we may be able to
promote computations in it into a wider type corresponding to the
"base type" of integers.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Kenner:

>      No, the language (or, more precisely, GNAT) defines them as 0 and
>      2**size - 1.  Otherwise the 'Valid attribute doesn't work.  Necessary
>      range checks will be optimized away, too.
>
> No, enumeration types are defined as having precisely the set of
> values specifically listed.

This is simply not true for Ada.  Look at the definition of the 'Valid
attribute in the standard:

  3. X'Valid

          Yields True if and only if the object denoted by X is normal
          and has a valid representation. The value of this attribute
          is of the predefined type Boolean.

If your claim were true, 'Valid could never return False for
enumeration types.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Richard Kenner wrote:
>     > compiler (specifically VRP) is *correct* in deducing that the values are
>     > in the valid range of the type *except* for 'Valid and range checks.
> 
>     You meant "for 'Valid range checks" right? (no "and").
> 
> I meant "and".  Range checks are essentially 'Valid.

no, range checks are quite different from validity checks.
range checks can assume data is valid, validity checks
can not make thisd assumption.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    > compiler (specifically VRP) is *correct* in deducing that the values are
    > in the valid range of the type *except* for 'Valid and range checks.

    You meant "for 'Valid range checks" right? (no "and").

I meant "and".  Range checks are essentially 'Valid.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Laurent GUERBY:

> An implementation model could be for the front-end to generate for each
> family of scalar type T a function Base_Type_Internal_Valid (X, Min,
> Max : in Base_Type_Of_T) return Boolean, generate a call to it at all
> 'Valid uses and then tell the compiler to never do any inlining at all
> on such generated function.

I think you could have a similar effect with an empty machine code
insertion.  But it's still a kludge.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Laurent GUERBY wrote:

> My understanding is that VRP (the compiler) is free to remove all other
> language mandated range checks based on type min/max information but has
> to keep the ones generated for 'Valid. 

and any implicit validity checks, and for gnat, validity checks from
-gnatVa
> 
> An implementation model could be for the front-end to generate for each
> family of scalar type T a function Base_Type_Internal_Valid (X, Min,
> Max : in Base_Type_Of_T) return Boolean, generate a call to it at all
> 'Valid uses and then tell the compiler to never do any inlining at all
> on such generated function.

sounds ver inefficient, remember that many left hand side array
references require implicit validity checks.
> 
> Since I think there are not that many scalar base types around, I guess
> such functions could even be included in the Ada RTS and not generated
> on the fly.
> 
> Of course performance wouldn't be as good as possible, but if
> there's no other way...
> 
> Laurent
> 

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Laurent GUERBY]

On Fri, 2005-08-12 at 11:53 -0400, Richard Kenner wrote:
> I'm not saying that things aren't broken, just being very careful in the
> definition of what a "valid" value in an object is.  The point is that these
> values are not "valid" (which is why 'Valid returns FALSE) and that the
> compiler (specifically VRP) is *correct* in deducing that the values are
> in the valid range of the type *except* for 'Valid and range checks.

You meant "for 'Valid range checks" right? (no "and").

My understanding is that VRP (the compiler) is free to remove all other
language mandated range checks based on type min/max information but has
to keep the ones generated for 'Valid.

An implementation model could be for the front-end to generate for each
family of scalar type T a function Base_Type_Internal_Valid (X, Min,
Max : in Base_Type_Of_T) return Boolean, generate a call to it at all
'Valid uses and then tell the compiler to never do any inlining at all
on such generated function.

Since I think there are not that many scalar base types around, I guess
such functions could even be included in the Ada RTS and not generated
on the fly.

Of course performance wouldn't be as good as possible, but if
there's no other way...

Laurent

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    The Ada front end works by doing an unchecked conversion of X to
    t'Base, followed by a range check. The issue is to stop range
    propagation through the unchecked conversion.

And as we discussed on the phone, the core of the problem is that Gigi
treats unchecked conversions of numeric types as if they were normal
conversions (in order to make them work for different size types) and
GCC is (properly) propagating information through those conversions.

What has to happen is that we need some sort of way of indicating that it's
not permissible to derive information through a particular conversion.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Richard Kenner wrote:
>     which, contrary to your previous email, is definitely not an erroneous
>     situation.  Precision is very important here!
> 
> Yes, and I'm sorry for the confusion.  However, for the purposes of this
> discussion, there's no difference between erroneous and bounded error:
> the issue is whether it's right to say that the only "valid" values of
> the subtype are what's given by its range and that's the case whether
> an invalid value would be a bounded error or erroneous.

no, there is a big difference

   x'Valid must work if x is invalid

but x'valid is erroneous if x is abnormal

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Richard Kenner wrote:
>     Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a
>     way which is (now) incorrect, 
> 
> No, that usage is correct.  What's incorrect is the way that 'Valid and
> range checks are being implemented and/or optimized.  Those should not be
> using the bounds of the subtype.

they do not!!!!!
the use the bounds of the base type

the problem is that the 'Valid in Ada really has no
analog in C. Actually the Ada 95 RM had this wrong, and
did not create the special rule for 'Valid, but this
was obviously intended, so an AI was issued to correct
this. The AI ensures that the sequence

     X : t;
     ...
     if X'Valid ...

is correct and works as intended to test if the
uninitialized value in X is invalid.

The Ada front end works by doing an unchecked conversion
of X to t'Base, followed by a range check. The issue is
to stop range propagation through the unchecked conversion.

we certainly do NOT want to say that the bounds of t are the
same as the bounds of t'base, since then we lose the
valuable range optimizations in all other cases. Only 'Valid
is special!

P.S. i do think that for the enum type the argument should
be the unsigned "base type". I will fix this
but it won't help the more general case

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Giovanni Bajo wrote:
> Robert Dewar <dewar@adacore.com> wrote:

> Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way
> which is (now) incorrect, and this causes wrong optimizations. Of course,
> this might be seen as an evolution (the exact semantics weren't as clear
> before), but it does not change things.

i may not know enougn here. but i thought that these were fields
associated with the type.

if so that's a wrong model for ada, where there are two situations:

a) constrycts which are allowed to assume in range

b) constructs which are not allowed to make this assumption

how do wedistinguish these cases. right now, the front end assumes
that the backend will essentially assume a) everywhere, and it
widens the type in cases b) using unchecked conversions. assuming
that uc's should be a barrier to range propagation.
> 
> You can either disable the optimization or fix Gigi. I'd also note that you
> already have SRA disabled, which is an optimization which would be *very*
> useful to Ada, because of other Gigi bugs.

really not clear to me what the fix is here

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    which, contrary to your previous email, is definitely not an erroneous
    situation.  Precision is very important here!

Yes, and I'm sorry for the confusion.  However, for the purposes of this
discussion, there's no difference between erroneous and bounded error:
the issue is whether it's right to say that the only "valid" values of
the subtype are what's given by its range and that's the case whether
an invalid value would be a bounded error or erroneous.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a
    way which is (now) incorrect, 

No, that usage is correct.  What's incorrect is the way that 'Valid and
range checks are being implemented and/or optimized.  Those should not be
using the bounds of the subtype.

    I'd also note that you already have SRA disabled, which is an
    optimization which would be *very* useful to Ada, because of other
    Gigi bugs.

No, SRA is disabled due to a very subtle front-end issue having to do
with renamed discriminants in cases where the resulting subtype has
fewer fields than the original record.  The front end has to include the
"nonexistant" fields in the subtype for Gigi's use but in a way that
won't interfere with front-end semantics.  This has been on the to-do list
for the front end folks for quite a while.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Richard Kenner wrote:
>     Quote from section 13.9.1 follows.  Note the "but does not by itself
>     lead to erroneous or unpredictable execution" part.
> 
> Right, because it's a "bounded error".

which, contrary to your previous email, is
definitely not an erroneous situation.
Precision is very important here!

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Giovanni Bajo]

Robert Dewar <dewar@adacore.com> wrote:

> why can't we just
> completely turn off this optimization for Ada since it is wrong!


Well, the point is that Gigi uses the fields TYPE_MIN/MAX_VALUE in a way
which is (now) incorrect, and this causes wrong optimizations. Of course,
this might be seen as an evolution (the exact semantics weren't as clear
before), but it does not change things.

You can either disable the optimization or fix Gigi. I'd also note that you
already have SRA disabled, which is an optimization which would be *very*
useful to Ada, because of other Gigi bugs.
-- 
Giovanni Bajo

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Richard Kenner wrote:
>     > Well sure, reading an uninitialized value is erroneous except for the use
>     > of 'Valid.
> 
>     No, it's not, as Ada is not C.  
> 
> What's "not"?  My statement is based on the Ada RM.

the rm is quite clear, lack of initialization
never leads to erroneous behavior. an uninitialized
variable may have an invalid value, but is not
abnormal. For example it is not a valid
implementation for

   a(i) := 0;

to overwrite memory outside the array a when
i is uninitialized, a validity check is
required here. same thing with case
statements.
> 
>     And please note the presence of pragma Normalize_Scalars.
> 
> That doesn't affect validity or erroneousness.

the progrm is not erroneous in either case

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Richard Kenner wrote:
>     If this still doesn't convince you, here's an example which doesn't
>     use Ada.Unchecked_Conversion at all.
> 
> Well sure, reading an uninitialized value is erroneous except for the use
> of 'Valid.

That is wrong, it is a bounded error. and of course validit checks must
work as described in the ghnat rm.
> 
> I'm not saying that things aren't broken, just being very careful in the
> definition of what a "valid" value in an object is.  The point is that these
> values are not "valid" (which is why 'Valid returns FALSE) and that the
> compiler (specifically VRP) is *correct* in deducing that the values are
> in the valid range of the type *except* for 'Valid and range checks.

right, but range ckecks for validity checking arr crucial
> 
> Those checks need to be done another way, such as by using the "base type".
> The issues with that have to do with debug output, representation within
> Gigi, and whether the NOP_EXPRs that would have to be used to implement
> that will be maintained.

the are done with the base type now!

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    Quote from section 13.9.1 follows.  Note the "but does not by itself
    lead to erroneous or unpredictable execution" part.

Right, because it's a "bounded error".

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Kenner:

>     > Well sure, reading an uninitialized value is erroneous except for the use
>     > of 'Valid.
>
>     No, it's not, as Ada is not C.  
>
> What's "not"?  My statement is based on the Ada RM.

Quote from section 13.9.1 follows.  Note the "but does not by itself
lead to erroneous or unpredictable execution" part.

                         Bounded (Run-Time) Errors

  9. If the representation of a scalar object does not represent a
     value of the object's subtype (perhaps because the object was not
     initialized), the object is said to have an invalid
     representation. It is a bounded error to evaluate the value of
     such an object. If the error is detected, either Constraint_Error
     or Program_Error is raised. Otherwise, execution continues using
     the invalid representation. The rules of the language outside this
     subclause assume that all objects have valid representations. The
     semantics of operations on invalid representations are as follows:

      10. If the representation of the object represents a value of the
          object's type, the value of the type is used.

      11. If the representation of the object does not represent a
          value of the object's type, the semantics of operations on
          such representations is implementation-defined, but does not
          by itself lead to erroneous or unpredictable execution, or to
          other objects becoming abnormal.

>     And please note the presence of pragma Normalize_Scalars.
>
> That doesn't affect validity or erroneousness.

It affects predictability.  As Robert wrote, the test case must print
SUCCESS.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    > Well sure, reading an uninitialized value is erroneous except for the use
    > of 'Valid.

    No, it's not, as Ada is not C.  

What's "not"?  My statement is based on the Ada RM.

    And please note the presence of pragma Normalize_Scalars.

That doesn't affect validity or erroneousness.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Kenner:

>     If this still doesn't convince you, here's an example which doesn't
>     use Ada.Unchecked_Conversion at all.
>
> Well sure, reading an uninitialized value is erroneous except for the use
> of 'Valid.

No, it's not, as Ada is not C.  And please not the presence of pragma
Normalize_Scalars.

> I'm not saying that things aren't broken, just being very careful in the
> definition of what a "valid" value in an object is.

To be honest, I think your definitions don't match what is described
in the in the ARM and the GNAT RM.

> The point is that these values are not "valid" (which is why 'Valid
> returns FALSE) and that the compiler (specifically VRP)

This is not a VRP bug.  It also happens with GCC 4.0.1.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

    If this still doesn't convince you, here's an example which doesn't
    use Ada.Unchecked_Conversion at all.

Well sure, reading an uninitialized value is erroneous except for the use
of 'Valid.

I'm not saying that things aren't broken, just being very careful in the
definition of what a "valid" value in an object is.  The point is that these
values are not "valid" (which is why 'Valid returns FALSE) and that the
compiler (specifically VRP) is *correct* in deducing that the values are
in the valid range of the type *except* for 'Valid and range checks.

Those checks need to be done another way, such as by using the "base type".
The issues with that have to do with debug output, representation within
Gigi, and whether the NOP_EXPRs that would have to be used to implement
that will be maintained.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Robert Dewar:

> Florian Weimer wrote:
>
>> I fear that such barriers are also needed for all checks on scalars,
>> by the way, not just 'Valid.
>
> indded, and we do unchecked conversions to the base type in these
> cases. i guess we could fix the enum case by using unsigned as the
> arg type, but that would not help the general case.

It would also fail when the 'Valid code is inlined and the tree
optimizers propagate the range information present in the enumeration
type.

> why can't we just completely turn off this optimization for Ada
> since it is wrong!

If I read the documentation correctly, you have to set
TYPE_MAX_VALUE/TYPE_MIN_VALUE to the values for the base type.
However, GIGI uses these attributes for other things besides
passing data to the middle end, so it's not an easy change.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Florian Weimer wrote:

> I fear that such barriers are also needed for all checks on scalars,
> by the way, not just 'Valid.

indded, and we do unchecked conversions to the base type in these
cases. i guess we could fix the enum case by using unsigned as the
arg type, but that would not help the general case. why can't we just
completely turn off this optimization for Ada since it is wrong!

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Robert Dewar:

> Florian Weimer wrote:
>> If this still doesn't convince you, here's an example which doesn't
>> use Ada.Unchecked_Conversion at all.
>
> this example must print Success, that is guaranteed by the RM

Yes, I think so.

What about the first one in PR21573?  IMHO, the GNAT Reference Manual
makes a guarantee that it prints SUCESS, too, but I could be
misreading the documentation.

> it is definitely critical that 'Valid not make "in-range"
> assumptions.

> the actual problem is optimization of this
> routine presumably:

>       function bug3_p__tRP (A : bug3_p__t; F : boolean) return integer is

Indeed.  In this case, bug3_p__t has TYPE_MIN_VALUE and TYPE_MAX_VALUE
set according to T'First'Enum_Rep and T'Last'Enum_Rep.  Even without
VRP, add_case_node and node_has_high_bound in stmt.c check these
attributes and use them in optimizations.

> the unchecked conversion to unsigned must prevent any optimization.
> the optimizer must not be able to "see through" an unchecked conversion!

I don't think we currently have a convenient way to express such an
optimization barrier in the tree language.

I fear that such barriers are also needed for all checks on scalars,
by the way, not just 'Valid.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Robert Dewar]

Florian Weimer wrote:
> 
> If this still doesn't convince you, here's an example which doesn't
> use Ada.Unchecked_Conversion at all.

this example must print Success, that is guaranteed by the RM

it is definitely critical that 'Valid not make "in-range"
assumptions. the actual problem is optimization of this
routine presumably:

       function bug3_p__tRP (A : bug3_p__t; F : boolean) return integer is
       begin
          case system__unsigned_types__unsigned!(A) is
             when 2 =>
                return 0;
             when 3 =>
                return 1;
             when 5 =>
                return 2;
             when 7 =>
                return 3;
             when others =>
                [constraint_error when F "invalid data"]
                return -1;
          end case;
       end bug3_p__tRP;

the unchecked conversion to unsigned must prevent any optimization.
the optimizer must not be able to "see through" an unchecked conversion!

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Kenner:

>      Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
>      Checking) require that such reads are NOT erroneous.
>
> It depends what "such reads" mean.  13.9.1(12) clearly says that the
> result of an Unchecked_Conversion is erroneous if it isn't a valid
> representation.  There are some cases, however, where an out-of-range
> value is a bounded error instead of being erroneous.
>
> However, note 20 (13.9.2) says that 'Valid is not considered a "read"
> and hence its use is not erroneous.

I'm sorry for my rude discussion style.  I was a bit frustrated
because of some unrelated matters.

I think the GNAT documentation makes additional guarantees.  If you
think this is wrong, the documentation can be fixed, of course.  In
addition, the first example in PR21573 follows your advice and applies
'Valid to the result of an instantiation of Ada.Unchecked_Conversion.
This still doesn't work.

If this still doesn't convince you, here's an example which doesn't
use Ada.Unchecked_Conversion at all.

--  Another test case for PR21573.  Note that if PR23354 is fixed and
--  X is initialized to a different value, this test case might no
--  longer check the same bug (but it should still print SUCCESS).
--  (The Bug3_P package is necessary to prevent compile-time
--  evaluation.)

pragma Normalize_Scalars;

with Bug3_P; use Bug3_P;

procedure Bug3 is

   X : U;
   --  The subtype causes X to be initialized with 0, according to the 
   --  current Normalize_Scalars rules.

begin
   Test (X);
end Bug3;

with Ada.Text_IO; use Ada.Text_IO;

package Bug3_P is

   type T is (A, B, C, D);
   for T'Size use 8;
   for T use (A => 2, B => 3, C => 5, D => 7);

   subtype U is T range B .. D;

   procedure Test (X : T);

end Bug3_P;

package body Bug3_P is

   procedure Test (X : T) is
   begin
      --  Check with a debugger that X is zero at this point.
      if X'Valid then
         Put_Line ("FAIL");
      else
         Put_Line ("SUCCESS");
      end if;
   end Test;
end Bug3_P;

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

     Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
     Checking) require that such reads are NOT erroneous.

It depends what "such reads" mean.  13.9.1(12) clearly says that the
result of an Unchecked_Conversion is erroneous if it isn't a valid
representation.  There are some cases, however, where an out-of-range
value is a bounded error instead of being erroneous.

However, note 20 (13.9.2) says that 'Valid is not considered a "read"
and hence its use is not erroneous.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Kenner:

>      This is simply not true for Ada.  Look at the definition of the 'Valid
>      attribute in the standard:
>
>        3. X'Valid
>
>           Yields True if and only if the object denoted by X is normal
>           and has a valid representation. The value of this attribute
>           is of the predefined type Boolean.
>
> Right.  That says what a "valid representation" is.  Except for the
> result of an unchecked_conversion being given as the operand of 'Valid,
> any other value in that type is erroneous.

Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity
Checking) require that such reads are NOT erroneous.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

     Well, perhaps yes, perhaps no.  What I don't know is if it is
     actively illegal to assign 0 to an enumeration that doesn't
     contain 0 as a member.

It's not "illegal", but there's no way to do it in the language without using
an Unchecked_Conversion (or similar sorts of punning).  And if the
Unchecked_Conversion produced a result that did not correspond to the value
of an enumeration literal, the only non-erroneous use of that value is as the
operand of 'Valid.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

     This is simply not true for Ada.  Look at the definition of the 'Valid
     attribute in the standard:

       3. X'Valid

          Yields True if and only if the object denoted by X is normal
          and has a valid representation. The value of this attribute
          is of the predefined type Boolean.

Right.  That says what a "valid representation" is.  Except for the
result of an unchecked_conversion being given as the operand of 'Valid,
any other value in that type is erroneous.

    If your claim were true, 'Valid could never return False for
    enumeration types.

I think you misunderstand what 'Valid is.  It tests for objects being *in
the type*.  If the type were in fact the full range, then 'Valid would
always return True.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Henderson:

> On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote:
>>       TYPE_MIN_VALUE (gnu_scalar_type)
>> 	= gnat_to_gnu (Type_Low_Bound (gnat_entity));
>>       TYPE_MAX_VALUE (gnu_scalar_type)
>> 	= gnat_to_gnu (Type_High_Bound (gnat_entity));
>> 
>> This is wrong (as discussed before) and is likely the cause of PR21573
>> (not VRP-related, the expanders for SWITCH_EXPR look at these
>> attributes, too).  I'm not sure if it is safe to delete these
>> assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
>> quite extensively throught GIGI.
>
> Well, perhaps yes, perhaps no.  What I don't know is if it is
> actively illegal to assign 0 to an enumeration that doesn't
> contain 0 as a member.

Illegal from which viewpoint?  Language definition or GCC optimizers?

> It's clear that if it is in fact illegal, that the Ada front
> end has to use some other type than the enumeration to validate
> the values going into the enumeration.

In the Ada case, all the necessary compile-time checks should be
performed by the front end anyway.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Henderson]

On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote:
>       TYPE_MIN_VALUE (gnu_scalar_type)
> 	= gnat_to_gnu (Type_Low_Bound (gnat_entity));
>       TYPE_MAX_VALUE (gnu_scalar_type)
> 	= gnat_to_gnu (Type_High_Bound (gnat_entity));
> 
> This is wrong (as discussed before) and is likely the cause of PR21573
> (not VRP-related, the expanders for SWITCH_EXPR look at these
> attributes, too).  I'm not sure if it is safe to delete these
> assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
> quite extensively throught GIGI.

Well, perhaps yes, perhaps no.  What I don't know is if it is
actively illegal to assign 0 to an enumeration that doesn't
contain 0 as a member.

It's clear that if it is in fact illegal, that the Ada front
end has to use some other type than the enumeration to validate
the values going into the enumeration.  Which could be construed
as the case with 21573 -- we should have used an int32_t equivalent
instead of the enumeration.


r~

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Kenner:

>      This is wrong (as discussed before) and is likely the cause of PR21573
>      (not VRP-related, the expanders for SWITCH_EXPR look at these
>      attributes, too).  I'm not sure if it is safe to delete these
>      assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
>      quite extensively throught GIGI.
>
> Well, what *should* they be set to?  That is indeed setting them to the
> minimum and maximum values as defined by the language.

No, the language (or, more precisely, GNAT) defines them as 0 and
2**size - 1.  Otherwise the 'Valid attribute doesn't work.  Necessary
range checks will be optimized away, too.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

     This is wrong (as discussed before) and is likely the cause of PR21573
     (not VRP-related, the expanders for SWITCH_EXPR look at these
     attributes, too).  I'm not sure if it is safe to delete these
     assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
     quite extensively throught GIGI.

Well, what *should* they be set to?  That is indeed setting them to the
minimum and maximum values as defined by the language.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Florian Weimer]

* Richard Henderson:

> For the record, I believe we've addressed these issues sometime
> within the last year or two.  The TYPE_MIN/MAX_VALUE for an enum
> should be set to the range truely required by the relevant language
> standards (different between C and C++).
>
> I don't know for a fact that Ada has been adjusted for this though.

From GIGI (around line 4115 in declc):

  if ((kind == E_Enumeration_Type && Present (First_Literal (gnat_entity)))
      || (kind == E_Floating_Point_Type && !Vax_Float (gnat_entity)))
    {
      tree gnu_scalar_type = gnu_type;

      [...]

      TYPE_MIN_VALUE (gnu_scalar_type)
	= gnat_to_gnu (Type_Low_Bound (gnat_entity));
      TYPE_MAX_VALUE (gnu_scalar_type)
	= gnat_to_gnu (Type_High_Bound (gnat_entity));

This is wrong (as discussed before) and is likely the cause of PR21573
(not VRP-related, the expanders for SWITCH_EXPR look at these
attributes, too).  I'm not sure if it is safe to delete these
assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VALUE are used
quite extensively throught GIGI.

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Kenner]

     The TYPE_MIN/MAX_VALUE for an enum should be set to the range truely
     required by the relevant language standards (different between C and
     C++).

     I don't know for a fact that Ada has been adjusted for this though.

     But if an Ada developer can verify that enumerations are correctly
     created, we can delete about 100 lines of code.  Which would be nice.

I'm not sure I understand what "correct" means in this context.  Ada just
calls make_signed_type or make_unsigned_type and changes it to an
ENUMERAL_TYPE.  But it's pretty trivial to do whatever "correct" is, so
if you're specific, it's easy to do.  (There's not much code involved:
it's case E_Enumeration_Type in ada/decl.c:gnat_to_gnu_entity.)

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

[Richard Henderson]

On Fri, Aug 05, 2005 at 11:57:45AM -0600, Jeffrey A Law wrote:
> IIRC the C standard does not guarantee that an object stay within
> the bounds of its enumerated type.  You'll have to do some digging
> in the relevant standards.

For the record, I believe we've addressed these issues sometime
within the last year or two.  The TYPE_MIN/MAX_VALUE for an enum
should be set to the range truely required by the relevant language
standards (different between C and C++).

I don't know for a fact that Ada has been adjusted for this though.

The minimum Definitely Correct change at the moment appears to be

-    int width = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (arg1)));
+    int width = TYPE_PRECISION (TREE_TYPE (arg1));

But if an Ada developer can verify that enumerations are correctly
created, we can delete about 100 lines of code.  Which would be nice.


r~