On Wed, Jun 5, 2019 at 10:03 PM Eric Botcazou <ebotca...@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
