On 3/16/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-16 at 10:43 +0100, Richard Guenther wrote:
> > On 3/16/06, Geert Bosch <[EMAIL PROTECTED]> 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.
