> I wonder what this exception in VRP looks like? I wasn't specifically referring to an exception in VRP. I think that, when checks are off, it would be sufficient for gigi to emit sort of assertions for arguments on function entry (like your VRP patch did) and for return values on function calls; VRP would then just propagate them.
Could ASSERT_EXPR be used for this purpose, i.e. could it be made a first class GENERIC (or GIMPLE) expression that front-ends could emit (during gimplification)? > I also wonder if adding a test to the gimplifier that all integral typed > DECL types have NULL TREE_TYPE and TYPE_MIN/MAX_VALUE according to their > TYPE_PRECISION would pass with your changes (there may be such odd cases > with other frontends ...). Note that the changes don't eliminate subtypes (gigi generates the same GENERIC code), their actual bounds are only made private to gigi and their visible bounds set to that of the base type; IOW there is no lowering pass, except for the gimplification that will remove unnecessary casts. I think that the invariant should be that all integral types that appear in the code (types for declarations and expressions) have maximal bounds for their precision; "range" types should only be descriptive. -- Eric Botcazou