Joseph S. Myers wrote: > On Fri, 20 Jan 2012, Georg-Johann Lay wrote: > >> Hi. >> >> avr-gcc implements a 24-bit scalar integer types __int24 and __uint24 in >> avr.c:TARGET_INIT_BUILTINS like so: >> >> tree int24_type = make_signed_type (GET_MODE_BITSIZE (PSImode)); >> tree uint24_type = make_unsigned_type (GET_MODE_BITSIZE (PSImode)); >> >> (*lang_hooks.types.register_builtin_type) (int24_type, "__int24"); >> (*lang_hooks.types.register_builtin_type) (uint24_type, "__uint24"); >> >> PSImode is defined in avr-modes.c: >> >> FRACTIONAL_INT_MODE (PSI, 24, 3); >> >> Is this the right definition of a built-in type? > > FRACTIONAL_INT_MODE should work after Bernd's patch series from last July > relating to 40-bit types, though it's certainly possible there are issues > that appear with 24-bit types but not 40-bit types. > >> The question is because __int24 shreds the compiler, see PR51527 >> >> So the question is if there is something missing or broken in the definition >> above or if it's actually a flaw in the front-end. >> >> For the __int128 there is much more code sprinkled over the compiler sources, >> so maybe it's not that easy to introduce a new, built-in type completely in >> the >> back-end? > > See my discussions with Bernd from last July. In essence, I don't think > we should spread such code across the compiler for each non-power-of-2 > size; ultimately we should go the other way, stop having any TImode or > __int128 references in files outside config/, libgcc/config/ etc. and have > targets using those modes and types choose to use the relevant source > files for them. (And, further along, the existence of HImode, SImode, > DImode ought to be target-dependent as well, with files in config/ that > are used by targets with 8-bit bytes but maybe not by any targets with > wider bytes.)
You mean that thread? http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00064.html and http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00079.html For the 128-bit integers there is just one type __int128 and unsigned variant is unsigned __int128, whereas for the 24-bit types are are two types: __int24 for signed and __uint24 for unsigned flavor. Is there an advantage of one approach over the other? Johann
