This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ada subtypes and base types


On 3/16/06, Laurent GUERBY <laurent@guerby.net> wrote:
> On Thu, 2006-03-16 at 10:43 +0100, Richard Guenther wrote:
> > On 3/16/06, Geert Bosch <bosch@adacore.com> wrote:
> > >
> > > On Mar 16, 2006, at 05:09, Robert Dewar wrote:
> > > > Not quite right. If you have an uninitialized variable, the value is
> > > > invalid and may be out of bounds, but this is a bounded error
> > > > situation,
> > > > not an erroneous program. So the possible effects are definitely NOT
> > > > unbounded, and the use of such values cannot turn a program erroneous.
> > > > (that's an Ada 95 change, this used to be erroneous in Ada 83).
> > >
> > > Actually, that's a good point and raises some potential issues:
> > > if we're never establish the invariant that a value of a type is in
> > > range, we can only use the base range for variables that might be
> > > used uninitialized. Any read of such a variable would then involve
> > > a range check.
> > >
> > >    package Uninitialized is
> > >       N : Positive;
> > >    end Uninitialized;
> > >
> > >    with Uninitialized;
> > >    procedure Test is
> > >       for J in 1 .. Uninitialized.N loop
> > >          ...
> > >       end loop;
> > >    end Test;
> > >
> > > In this case, GCC might replace the loop with
> > >     declare
> > >        J : Integer := 1;
> > >     begin
> > >        while J /= Uninitialized.N loop
> > >           ...
> > >           J := J + 1;
> > >        end loop;
> > >     end;
> > >
> > > which would be incorrect for N = 0.
> >
> > Uh - what do you expect here??  Does the Ada standard require a out-of-range
> > exception upon the first use of N?
>
> <<
> 13.9.1 Data Validity
>
>                           Bounded (Run-Time) Errors
>
> 9     {invalid representation} {bounded error (cause) [partial]} 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. {Program_Error (raised by failure of run-time check)}
> {Constraint_Error (raised by failure of run-time check)} 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:
>
>     9.a   Discussion: The AARM is more explicit about what happens when the
>           value of the case expression is an invalid representation.
>
>     9.b/2 Ramification: {AI95-00426-01} This includes the result object of
>           functions, including the result of Unchecked_Conversion, T'Input,
>           and imported functions.
>
> 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.
>
>     11.a/2 Implementation Note: {AI95-00426-01} This means that the
>           implementation must take care not to use an invalid representation
>           in a way that might cause erroneous execution. For instance, the
>           exception mandated for case_statements must be raised. Array
>           indexing must not cause memory outside of the array to be written
>           (and usually, not read either). These cases and similar cases may
>           require explicit checks by the implementation.
> >>
>
> So in this case the behaviour is implementation defined, from my reading
> an infinite loop is not contrary to the standard.
>
> > In this case, the frontend needs
> > to insert a proper
> > check.  You cannot expect the middle-end to avoid the above transformation, so
> > this is a frontend bug.
>
> Do the ME or the BE have a representation for potentially uninitalized
> variables? In the following case:
>
> procedure T2 is
>    type R is range 1 .. 10;
>    type T is array (R) of Integer;
>    I : R;
>    X : T;
> begin
>    X (I) := 0;
> end T2;
>
> The Ada FE will insert an explicit check, as seen when using
> gcc -c -gnatdg t2.adb:
>
>    [constraint_error when not (interfaces__unsigned_32!(i) >= 1 and then
>      interfaces__unsigned_32!(i) <= 10) "invalid data"]
>
> Will the ME or FE remove the check?

Yes it will - as we see from -O0 -fdump-tree-original:

  if ((interfaces__unsigned_32) i == 0 || i > 10)
    {
      __gnat_rcheck_06 ("t2.adb", 7);
    }
  else
    {

    }

it uses a regular NOP/CONVERT_EXPR which VRP happily will see through
(validly so).
It also misses the conversion for the i>10 check completely.  It needs to print

  if (VIEW_CONVERT_EXPR<interfaces__unsigned_32>(i) == 0
     || VIEW_CONVERT_EXPR<interfaces__unsigned_32>(i) > 10)

So, this is a bug in gigi here.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]