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 > >