Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE

Richard Biener richard.guenther@gmail.com
Fri Jun 7 07:02:00 GMT 2019


On Thu, Jun 6, 2019 at 4:04 PM Hans-Peter Nilsson
<hans-peter.nilsson@axis.com> wrote:
>
> > From: Eric Botcazou <ebotcazou@adacore.com>
> > Date: Wed, 05 Jun 2019 22:03:04 +0200
>
> > > This issue exists, not just for targets that can have their
> > > MAX_FIXED_MODE_SIZE more-or-less easily tweaked higher, but also
> > > for the 'bit-container' targets where it *can't* be set higher.
> > >
> > > Let's please DTRT and correct the code here in the middle-end,
> > > so we don't ICE for those targets and this line (gcc.dg/pr69973.c):
> > >  typedef int v4si __attribute__ ((vector_size (1 << 29)));
> > > (all listed targets happen to have Pmode == SImode)
> > >
> > > So, considering that: ok to commit?
> >
> > You'd need to audit the effects on other targets though.  Are we sure that we
> > want to do bitsizetype calculations in a larger mode on very embedded targets?
>
> IIUC, the precision of the bitsizetype is used on the host.
> (Which is bad for native builds.)  When bitsizetype objects end
> up on the target, they use the actual Pmode and not the larger
> precision mode.

The lager precision mode ends up being used to compute a
bit offset, that divided by BITS_PER_UNIT will be used
in Pmode indeed.  But offset computations in TImode definitely
happen on x86_64.

> The only "other targets" affected are the one I listed, where
> it's needed in order to be able to detect near-address-range
> overflow, as shown.
>
> So, it's a question of correctness, not want.
>
> Are you suggesting I need to follow where the precision of
> bitsizetype ends up in target code?  If so, can you please do
> that for Ada?  You may already have the answer for that.
>
> brgds, H-P



More information about the Gcc-patches mailing list