This is the mail archive of the gcc-patches@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: [PATCH] Improve PR30911 and PR31023, Ada and VRP


> > If VIEW_CONVERT_EXPR was used for all checks that ensure that a bounded
> > error does not turn into an unbounded error, then teaching VRP that
> > variables are in the range of their types would not result in a bounded
> > error escalating into an unbounded error.  In particular, assuming that
> > parameters are in the range of their types would not result in the bounded
> > error of them not being in range turning into an unbounded error.
> 
> Yes, this might be a valid (and subtle) reasoning: we would be entitled to 
> remove all useless checks based on the assumption that the parameters are in 
> the range of their types, except for the validity checks.  Since the latter 
> checks are already specifically protected wrt VRP, we could teach VRP about 
> these ranges, like Richard G. did and what gave him a clean ACATS.
> 
> > That said, it is not clear exactly what is allowed when there is a bounded
> > error.  For example, the Ada reference manual seems to require that
> > uninitialized values behave deterministically.  Suppose X is uninitialized
> > (using it is then a bounded error).  In the following code
> >   if X = 0 then
> >     do_something_with_X;
> >   end if;
> > must X have the value 0 in do_something_with_X?
> > [...]
> > If the type of X had the range 0 .. 0, then allowing VRP to reason based on
> > type ranges could likewise cause do_something_with_X to be executed in the
> > case of the bounded error of X containing an out of range value, i.e. not 0.
> 
> Indeed, but my understanding is that do_something_with_X must be prepared for 
> invalid values of X (i.e. non-null values) in any cases and behaves in a 
> bounded way for them, so there would be no error escalation.

So should Richard apply his patch then?  It would be nice to have a definitive
decision on these issues.  Even nicer if it was documented in gcc somewhere :)

Best wishes,

Duncan.


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