This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Get rid of awkward semantics for subtypes
On Sun, Apr 12, 2009 at 9:37 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> 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)?
Yes, we could do that. Though a simpler form may be preferable, like
directly specifying a constant range/anti-range instead of encoding these
in (multiple) ASSERT_EXPRs.
I will think of something.
As for Ada - both function entry and exit constraints will be checked by
the caller/callee, correct? So that once you inline VRP should be able
to derive the ranges from existing checks? Thus - a IPA VRP pass should
be able to verify these properties across functions?
>> 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.
Yes, I agree. I volunteer to prepare a verification pass that asserts this
property during gimplification.
Thanks,
Richard.