Patch: don't cap TYPE_PRECISION of bitsizetype at MAX_FIXED_MODE_SIZE

Richard Biener richard.guenther@gmail.com
Thu Jun 6 07:59:00 GMT 2019


On Wed, Jun 5, 2019 at 10:03 PM Eric Botcazou <ebotcazou@adacore.com> wrote:
>
> > 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?

I didn't actually write it down but originally wanted - what about adding
a way for the target to specify what type to use for bitsize_type?
We do have SIZETYPE so say that if BITSIZETYPE is defined then
use that (otherwise fall back to the existing mechanism)?  There may
not be a C type that maps to DImode for cris and it's not that
I like those C type names very much (probably a way to make the
macros independent of the chosen multilib?), so eventually a
BITSIZEMODE or BITSIZE_LARGER_THAN_MAX_FIXED_MODE_SIZE
macro?  That said, if BITSIZETYPE would work I'd prefer that just
for consistency.

Richard.

> --
> Eric Botcazou



More information about the Gcc-patches mailing list