Re: Soft Float is not being reported

["Dave" <dave at cc0 dot net>]

>> Why would one want VFP softfloat. I spent some time researching VFP the
>> other day and I still don't understand why it would/should be used in any
>> case.

> VFP uses native endianness for storing floats, and I simply presume
> this is more efficient.  Nicholas Pitre even calls the FPA format a
> "historical mistake" here:
>
>
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-December/018687.html
>
> and here is also a somewhat more detailed explanation:
>
> http://lists.debian.org/debian-arm/2003/10/msg00030.html
>
> OTOH, software floating point is always quite slow, so the difference
> between softfpa and softvfp should not be too great.  I haven't
> actually benchmarked it... not enough time, I'm afraid. :)

So from what I gather now...

When doing soft-float in userland (no kernel FP emulator) on ARM, we should
be using VFP (softvfp) pretty much always because VFP will use the native
byte ordering method in use on target and in use by the gcc cross/native
compiler.

This makes good sense...

>
>> So basically if I get gcc stage 1 to output softfloat by default, then
build
>> glibc with CC="arm-linux-gcc -msoft-float" I *should* end up with a
>> softfloat libgcc + softfloat glibc?
>
> No, if you build gcc stage 1 with default softfloat output, you DON'T
> need to pass the -msoft-float flag anymore to the glibc and gcc-final
> stages.  In fact, you never have to use it anymore, since all object
> files will have softfloat already.

Got it!


-Dave




------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com