Re: How to define a built-in 24-bit type?
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
forcing the linker to be a particular one (i.e. gold vs bfd)
Hello, In a one year old thread, there was a discussion about a patch adding -fuse-ld=gold and -fuse-ld=bfd options to GCC. It seems the GCC part of the patch was never actually committed, as there were some problems with LTO: http://sourceware.org/ml/binutils/2011-01/msg00287.html Unfortunately there was no detail about what these problems were. Could someone elaborate? Are there plans to actually bring such a feature? Thanks Christophe.
Re: forcing the linker to be a particular one (i.e. gold vs bfd)
On Wed, Jan 25, 2012 at 3:43 PM, Christophe Lyon wrote: > Hello, > > In a one year old thread, there was a discussion about a patch adding > -fuse-ld=gold and -fuse-ld=bfd options to GCC. > > It seems the GCC part of the patch was never actually committed, as there > were some problems with LTO: > http://sourceware.org/ml/binutils/2011-01/msg00287.html > > Unfortunately there was no detail about what these problems were. > > Could someone elaborate? > > Are there plans to actually bring such a feature? You can change the linker used by adjusting your path or giving an appropriate -B option to the gcc driver. Richard.
Re: forcing the linker to be a particular one (i.e. gold vs bfd)
On 25.01.2012 15:49, Richard Guenther wrote: You can change the linker used by adjusting your path or giving an appropriate -B option to the gcc driver. Richard. Yes, but part of the thread was precisely to discuss alternatives, more end-user friendly (for those won't know the full path to alternate linker). Christophe.
Re: forcing the linker to be a particular one (i.e. gold vs bfd)
On Wed, Jan 25, 2012 at 3:55 PM, Christophe Lyon wrote: > On 25.01.2012 15:49, Richard Guenther wrote: >> >> >> You can change the linker used by adjusting your path or giving an >> appropriate -B option to the gcc driver. >> >> Richard. >> > Yes, but part of the thread was precisely to discuss alternatives, more > end-user friendly (for those won't know the full path to alternate linker). Would they know that two different linkers exist, or even what a linker is? Richard.
Re: How to define a built-in 24-bit type?
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. -- Joseph S. Myers jos...@codesourcery.com
Re: How to define a built-in 24-bit type?
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
Re: forcing the linker to be a particular one (i.e. gold vs bfd)
On 25.01.2012 16:14, Richard Guenther wrote: On Wed, Jan 25, 2012 at 3:55 PM, Christophe Lyon wrote: On 25.01.2012 15:49, Richard Guenther wrote: You can change the linker used by adjusting your path or giving an appropriate -B option to the gcc driver. Richard. Yes, but part of the thread was precisely to discuss alternatives, more end-user friendly (for those won't know the full path to alternate linker). Would they know that two different linkers exist, or even what a linker is? Richard. Yes they do, but as Matthias Klose said, it would help distribution makers (see http://sourceware.org/ml/binutils/2011-01/msg00191.html) Maybe Matthias remembers which problems he found with his patch and LTO? Thanks Christophe.
Re: fixed_scalar_and_varying_struct_p and varies_p
Richard Guenther writes: > I'd say open a missed optimization bug with the testcase and go ahead > with both patches. OK, I committed the patches yesterday and I've just opened PR 52000 for the missed optimisation. Richard
Re: How to define a built-in 24-bit type?
On 01/21/2012 01:48 AM, Georg-Johann Lay wrote: > FRACTIONAL_INT_MODE (PSI, 24, 3); Unrelated to everything else, I'm not sure you want a *fractional* mode. You're using all bits of the 3 bytes of storage. Fractional modes are those where there are unused bits of the in-memory representation. E.g. when a 20 bit quantity is stored in 3 bytes. r~
Re: How to define a built-in 24-bit type?
Richard Henderson schrieb: On 01/21/2012 01:48 AM, Georg-Johann Lay wrote: FRACTIONAL_INT_MODE (PSI, 24, 3); Unrelated to everything else, I'm not sure you want a *fractional* mode. You're using all bits of the 3 bytes of storage. Fractional modes are those where there are unused bits of the in-memory representation. E.g. when a 20 bit quantity is stored in 3 bytes. Yes you are right. All bits are used and it should be an int mode. I tried that back then but it shred the compiler, so that I used the partial mode and then it worked... Johann
