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

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

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

> > Sure, it's just that overloading V_C_E like this feels somehow wrong to me.
> 
> Why?  It's not "overloading".  V_C_E of an expression E of type X to
> type Y means "interpret the bits of E as if it were type Y and not type X".
> If Y is X'Base, then interpreting E as being Y means that it can now have
> all the values of Y.

For example, after the view conversion it is legal to place a value in it that
is in the range of Y but not of X.  This is logical.  What seems illogical to
me is that by doing the V_C_E you are supposed to forget anything you had
deduced about the bits before the conversion.  For example, suppose you had
deduced that the bits were all zero.  After the V_C_E the bits will still be
zero - are you really supposed to forget this information?  Another example:
suppose you had worked out somehow that the bits corresponded to an integer
in the range 4..5.  After the V_C_E this is still true - why is it logical
to forget this information?  You may well respond that you are only supposed
to forget information you deduced from the range of the type, not information
you worked out by some other means.  But these cannot really be distinguished,
c.f. VRP.

In short, it is overloading because it means: consider this bunch of bits
to be of the new type AND forget anything you ever deduced about them.

> In other words, we could only change a V_C_E to a 
> NOP_EXPR if we can prove that the value of E is in range of *both* X
> and Y.

Surely you only have to prove that it is in the range of Y, since if it
is not in the range of X then you have a bounded error, and doing a NOP_EXPR
should be perfectly legal.

> Of course, we still have a bit of a mess here in that the real point is
> a confusion between what in Ada is called a Bounded Error and C's notion
> of "undefined" (Ada's "erroneous").  But I think we can do better in this
> area: we just haven't gotten to take a really good look at it.
> 
> > However I haven't been able to put my finger on any technical obstacle to
> > this use of V_C_E.
> 
> Nor can I ...

Actually I do have a technical objection, however it comes from my LLVM
port and not mainline gcc.  LLVM is lower level than gimple.  Supposing
types X and Y have eg 32 bits, then they both get mapped to LLVM's Int32
type.  A V_C_E gets turned into nothing at all.  There are no types with
restricted ranges.  Suppose x is a variable of type X.  When a value is
loaded into x I'm planning on generating the following LLVM code:
        x = value;
        assert(x >= lower_bound_for_gcc_type && x <= upper_bound_for_gcc_type);
I don't generate the assert when you do a V_C_E, so for example suppose there
is a y = V_C_E(Y, x).  This gets turned into:
        y = x;
Since the optimizers have range info for x, they instantly deduce the same
ranges for y as for x.  Thus if you test for validity of y using
        valid = (y >= lower_bound_for_gcc_type_X && y <=
upper_bound_for_gcc_type-X);
then the result is always true.  How to get around this?  The obvious method is
to
use an intrinsic, such as __builtin_nop.  For the V_C_E I can then do:
        y = __builtin_nop(x);
and all will be well.  However, I only really need to use the __builtin_nop if
I'm doing the V_C_E in order to implement 'Valid.  For other uses of V_C_E it
is unnecessary and gets in the way of optimization.  So I would much rather
that
'Valid directly made use of a builtin.

Ciao,

Duncan.


-- 


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