On Wed, Aug 17, 2022 at 3:38 PM Eric Botcazou <botca...@adacore.com> wrote:
>
> > Hmm, can we instead do
> >
> >   if (!integer_zerop (lowbnd) && tree_fits_shwi_p (lowbnd))
> >    {
> >       const offset_int lb = offset_int::from (lowbnd, SIGNED);
> > ...
> >
> > ?
>
> Apparently not:
>
> In file included from /home/eric/cvs/gcc/gcc/coretypes.h:460,
>                  from /home/eric/cvs/gcc/gcc/pointer-query.cc:23:
> /home/eric/cvs/gcc/gcc/wide-int.h: In instantiation of
> 'wide_int_ref_storage<SE, HDP>::wide_int_ref_storage(const T&) [with T =
> tree_node*; bool SE = false; bool HDP = true]':
> /home/eric/cvs/gcc/gcc/wide-int.h:782:15:   required from
> 'generic_wide_int<T>::generic_wide_int(const T&) [with T = tree_node*; storage
> = wide_int_ref_storage<false>]'
> /home/eric/cvs/gcc/gcc/pointer-query.cc:1803:46:   required from here
> /home/eric/cvs/gcc/gcc/wide-int.h:1024:48: error: incomplete type
> 'wi::int_traits<tree_node*>' used in nested name specifier
>  1024 |   : storage_ref (wi::int_traits <T>::decompose (scratch,
>       |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
>  1025 |                                                 wi::get_precision (x),
> x))
>       |
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> And:
>
>   const offset_int lb = wi::to_offset (lowbnd);
>
> compiles but does *not* fix the problem since it does a zero-extension.

Meh.  OK, eventually would need "indirection" through a wide-int then.
Like

  offset_int::from (wi::to_wide (lowbnd), TYPE_SIGN (TREE_TYPE (lowbnd)))

?

> [Either extension is fine, as long as it's the same in get_offset_range].

I think it should extend according to sing of lowbnd?  Or does Ada
use an unsigned lowbnd to represent a signed value here?  At least
that's what I had issues with with your patch.

> > In particular interpreting the unsigned lowbnd as SIGNED when
> > not wlb.get_precision () < TYPE_PRECISION (sizetype), offset_int
> > should handle all positive and negative byte offsets since it can
> > also represent them measured in bits.  Unfortunately the
> > wide_int classes do not provide the maximum precision they can
> > handle.  That said, the check, if any, should guard the whole
> > orng adjustment, no?  (in fact I wonder why we just ignore lowbnd
> > if it doesn't fit or is variable...)
>
> Yes, tree_fits_uhwi_p (or tree_fits_shwi_p) is bogus here, but the test
> against INTEGER_CST is used everywhere else and should be good enough.
>
> --
> Eric Botcazou
>
>

Reply via email to