https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Georg-Johann Lay from comment #16) > (In reply to Richard Biener from comment #14) > > Fixed on trunk sofar. Joseph correctly mentioned that iff AVR would define > > __int24 using INT_N in avr-modes.def the issue would have been mitigated as > > well > > (that's a comparatively "modern" way of registering additional integer > > types). > > > > So it's really also a target issue. > > INT_N isn't even mentioned in the internals documentation. > > And are you saying that FRACTIONAL_INT_MODE is bogus or broken by design? No, INT_N is just a convenient way to add new builtin types that are accessible as [u]intN_t to the user. Those happened to be considered already for the conversions.
