On Tue, Mar 30, 2010 at 2:29 PM, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Tue, 30 Mar 2010, Paulo J. Matos wrote: > >> GCC is generating a call to floatunsihf when it needs to convert an >> unsigned integer to a float. And this call is being generated because >> I am compiling to a 16bit target, where floats are 32, meaning floats >> are HFmode. > > No, HFmode only exists if you specifically define it to exist for a > target. Unless you really know what you are doing, you should not define > it until you have ordinary float (SFmode) working. If HFmode calls are > generated without having defined it as a target-specific mode, something > is wrong you need to resolve. >
I didn't define the HFmode but gcc still generates this call (reason is below). > The basic unit for machine modes is QImode, meaning one byte - > BITS_PER_UNIT bits (8 bits unless you know exactly what you are doing and > are prepared to fix many broken and bit-rotten cases in > machine-independent code). HImode and HFmode are modes of 2*BITS_PER_UNIT > bits. SImode and SFmode are modes of 4*BITS_PER_UNIT bits. So presuming > BITS_PER_UNIT is 8, a 32-bit float should be SFmode; a 16-bit integer > value should be HImode (for any target with 8-bit bytes, whatever the word > size). > I have 16 BITS_PER_UNIT for this target, with 1 UNITS_PER_WORD. If I define FLOAT_TYPE_SIZE to be 32, then a float is an HFmode and it's not that gcc uses this. Defining BITS_PER_UNIT to 16 shouldn't generate problems inside the compiler given that GCC has generic treatment for these situations (otherwise GCC should state that only BITS_PER_UNIT=8 is supported). The problem is how to integrate software floating point support for this target where a float is not SFmode 'as usual'. > -- > Joseph S. Myers > jos...@codesourcery.com > -- PMatos
