Joseph S. Myers wrote: > On Wed, 25 Jan 2012, Georg-Johann Lay wrote: > >> 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 > > Yes, the whole thread (with particular reference to my comments about what > should be kept target-dependent). > >> 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? > > signed and unsigned __int128 is more consistent with standard C types, but > harder to implement within a back end because it involves a new keyword. > Two different type names can be implemented purely within your back end > without needing generic work elsewhere first to make that possible, but > users might expect to be able to use unsigned __int24 - or _Complex > __int24 - and find that won't work if you use the built-in typedef > approach.
Yes, I observed that supplying a type does not suffice to also have a respective complex type build/typedef'd basing on it. The 24-bit types use PSImode with TARGET_SCALAR_MODE_SUPPORTED_P (PSImode) = true. In my naive thinking I thought having a scalar mode is sufficient to build a canonical complex on it, which is not the case :-( Presumably it's one of these many nice-to-have-but-sooo-little-time-to-implement-it things in GCC to have an automatism like that. Complex types are not really exciting with integers, but with the new fixed-point types "automatic" complex would be cool feature, e.g. for signal processing applications. Johann
