Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE
Fri Jun 7 07:02:00 GMT 2019
On Thu, Jun 6, 2019 at 4:04 PM Hans-Peter Nilsson
> > From: Eric Botcazou <email@example.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