On Mon, Apr 24, 2023 at 1:51 PM Aldy Hernandez <al...@redhat.com> wrote:
>
>
>
> On 4/24/23 10:30, Richard Biener wrote:
> > On Mon, Apr 24, 2023 at 9:44 AM Aldy Hernandez via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> There is a call to contains_p() in ipa-cp.cc which passes incompatible
> >> types.  This currently works because deep in the call chain, the legacy
> >> code uses tree_int_cst_lt which performs the operation with
> >> widest_int.  With the upcoming removal of legacy, contains_p() will be
> >> stricter.
> >>
> >> OK pending tests?
> >>
> >> gcc/ChangeLog:
> >>
> >>          * ipa-cp.cc (ipa_range_contains_p): New.
> >>          (decide_whether_version_node): Use it.
> >> ---
> >>   gcc/ipa-cp.cc | 16 +++++++++++++++-
> >>   1 file changed, 15 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> >> index b3e0f62e400..c8013563796 100644
> >> --- a/gcc/ipa-cp.cc
> >> +++ b/gcc/ipa-cp.cc
> >> @@ -6180,6 +6180,19 @@ decide_about_value (struct cgraph_node *node, int 
> >> index, HOST_WIDE_INT offset,
> >>     return true;
> >>   }
> >>
> >> +/* Like irange::contains_p(), but convert VAL to the range of R if
> >> +   necessary.  */
> >> +
> >> +static inline bool
> >> +ipa_range_contains_p (const irange &r, tree val)
> >> +{
> >> +  if (r.undefined_p ())
> >> +    return false;
> >> +
> >> +  val = fold_convert (r.type (), val);
> >
> > I think that's wrong, it might truncate 'val'.  I think we'd want
> >
> >     if (r.undefined_p () || !int_fits_type_p (val, r.type ()))
> >       return false;
>
> This won't work for pointers.  Is there a suitable version that handles
> pointers as well?

Where does it not work?  And when do you get pointer values/types
where they mismatch sufficiently (how?) to make ranger unhappy?

> >
> > but then I wonder whether contains_p should have an overload
> > with widest_int or handle "out of bounds" values itself more gracefully?
>
> Only IPA is currently passing incompatible types to contains_p(), so I'd
> prefer to keep things stricter until there is an actual need for them.
>
> Thanks.
> Aldy
>

Reply via email to