[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails

["baldrick at free dot fr" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #38 from baldrick at free dot fr  2007-03-09 23:10 -------
Subject: Re:  [4.3 regression] ACATS cxh1001 fails

> > All the mess would be way easier if the FE would not expose the subtypes to
> > the middle-end...
> 
> I don't see how giving *additional* information could be bad: the middle-end
> is certainly free to ignore the bounds if it wants to!

Yes, it can ignore them entirely if it wants to, but it can't ignore them
partially.  For example, fold is happy to create values which lie outside
the range of the type (i.e. fold is ignoring the range information); as a
consequence any part of the ME that exploits range information will give
wrong results right now.

> The point is that the bounds *do* say something and provide useful
> information to optimizers.  The problem is that they don't say what the
> middle-end *wants* them to say!
> 
> What they *do* mean is that it's a "bounded error" for a variable to have a
> value outside of the given bounds.  What the middle-end *wants* them to mean
> is that it's *erroneous* for a variable to have a value outside of the given
> bounds.  We need to reconcile those two concepts.

I don't think the middle-end needs to know about this distinction.  In fact
it would be wise to keep such subtleties in the front-end.  That can be done
as follows: in situations that might lead to erroneous behavior if a variable
has a value outside it's range, you add a validity check and raise
Program_Error
if it fails (this is authorized by the Ada RM).  Thus in order to avoid
erroneousness you only need a reliable way of checking validity.

> From a pragmatic point of view, they aren't that different, but there are a
> couple of important exceptions.  The array bound on the LHS is one of them.

This is solved by adding a validity check before accessing the memory, see
above.

> A full solution to this is complex, but is indeed something that I'd like to
> happen some day.  It involves work in various places.  One thing that would
> help is that many variables can be proven to have the property that the only
> way they can have an invalid value is if erroneous behavior has occurred.
> For such variables, the meaning of the bounds is precisely what the
> middle-end expects it to mean.
> 
> The most common case where you can't do this is for component references or
> pointer dereferences.

I don't see that pointer dereferences are a problem - I'm pretty sure that
the RM places you firmly in the erroneous zone if you do something that can
give a pointer a bogus value.  That leaves array accesses.  If your index
is outside the range of the type, you can catch that and raise Program_Error.
Otherwise it is in range, so you load a value from the array (this value
may be uninitialized).  I believe this is OK for a bounded error.  In short
I don't see any problem here, or any need to track bounded/erroneous
behaviour around the program.  Do you have an example where you can't
prevent a bounded error being (wrongly) turned into erroneous behaviour
by the addition of a local check?

> In that case, we have to address this by 
> distinguishing between two types of tests, those that will just propagate the
> bounded error condition and those that would convert a bounded error to
> erroneous behavior.  We are allowed to use the bounds information in
> reasoning about the former, but not the latter.

Exactly, and I'm pretty sure that all you need to handle this is a reliable
way of doing validity checking.

> Note that there are similarities to the signed-overflow case here: there are
> some tests that we can safely eliminate with knowlege that signed-overflow is
> undefined, but others that we don't want to.
> 
> So I think the "final" solution here will be to have the Ada front end
> provide the flag information on variables and tests mentioned above and
> extend VRP to use them.  One of the two front-end issues (the latter) is
> quite easy and I think the other is moderately-easy.  I don't know how much
> work the required VRP changes would be.

I don't see why any such flags are required.  Why does validity checking
(implemented by V_C_E or an intrinsic or whatever) not suffice?

Ciao,

Duncan.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797