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 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?

Laurent


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