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

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

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. :)

Think of it as choosing the least dangerous of Charybdis and Scylla, 
while trying our best not to get near any of the two.

> Regards,
>
> Alexander

Amicalement,
-- 
Albert.