On Thu, Jun 6, 2019 at 4:04 PM Hans-Peter Nilsson <hans-peter.nils...@axis.com> wrote: > > > From: Eric Botcazou <ebotca...@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
