[U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 19/02/2011 15:34, M?ns Rullg?rd a ?crit :
> Albert ARIBAUD<albert.aribaud@free.fr>  writes:
>
>> Le 19/02/2011 15:06, Alexander Holler a ?crit :
>>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD:
>>>> Le 19/02/2011 14:25, M?ns Rullg?rd a ?crit :
>>>>
>>>>>> So whats the reasoning to use -msoft-float as it is currently done? To
>>>>>> confuse people? ;)
>>>>>
>>>>> I guess it's there to make sure no floating-point instructions make it
>>>>> into u-boot, even though floats are not used in the code. Perhaps
>>>>> someone was paranoid.
>>>>
>>>> I think also that there is no choice but to have a float option for ARM
>>>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with
>>>> the 'soft' calling conventions), because the C compiler does not allow
>>>> 'no floats', and anyway the C language *requires* to have some sort of
>>>> float support.
>>>
>>> As it is on every platform.
>>
>> Indeed.
>>
>>>> Actually if you don't specify any float option, the C toolchain will
>>>> choose one, which is just the same in the end: *some* float option is
>>>> chosen.
>>>
>>> Every compiler has dozens of options which are set to a default value.
>>
>> Granted. But not all of them relate to hardware which may or may not be
>> available.
>>
>>>> And since some option must be chosen, I prefer that U-Boot make the
>>>> explicit decision, and choose soft float for the reasons I already
>>>> exposed.
>>>
>>> I don't see any reason to explicitly set an option for something which
>>> isn't used, but I know of many reasons to avoid such. ;)
>>
>> At least there is one reason for having -msoft-float even though no
>> floating point should be used in U-Boot : it helps catching cases where
>> some code in U-Boot tries to use hard float. :)
>
> There is one further complication here.  If the compiler was built with
> -mfpu=neon as default, it might emit neon instructions for pure integer
> code.  For the purpose of this discussion, such instructions should
> still be regarded as floating-point since they are tied to the VFP.
> Such code generation is disabled by -msoft-float.

Thanks for indicating this. If I paraphrase this correctly, some 
toochains would generate floating instructions for integer if both 
-mfloat-abi=hard and -fmpu=neon were specified or were the default.

I don't see this as a worrying matter though, because I suspect that 
toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and 
target cpus that have hw floating point capabilities, where such float 
instructions would cause no problem.

And it is not as if the C code used floats.

Besides, so far I have seen no complaint that -msoft-float disabling 
-mfpu=neon causes any problem with U-Boot, so I suspect no board 
requires it now.

Amicalement,
-- 
Albert.