[OE-core] libm accuracy, eglibc compared to glibc -- solved

Mats Kärrman Mats.Karrman at tritech.se
Fri Mar 21 12:10:22 UTC 2014


Hi,

On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote:
> My "home made" hard float tune for PowerPC looks like this:
> 
> ------------------------------------------------------------------
> # Tune for the e300c3 core
> require conf/machine/include/tune-ppce300c3.inc
> 
> # Use hardware floating point
> AVAILTUNES += "ppce300c3hf"
> TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3"
> TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf"
> PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf = "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce300c3hf"
> DEFAULTTUNE = "ppce300c3hf"
> ------------------------------------------------------------------
> 

I found the reason for the error (deviance) in the sqrt function. glibc has
special code for PowerPC 603e core (e300 is an optimized variant of 603e).
By adding the following line to the tuning I now get the same result as
for all other environments that I've tried:

GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3", "-with-cpu=603e", "", d)}"

Does anyone know about the reason for having soft-float as the default and
only available alternative for e300c2/3 tunings?

Would it be worthwhile to send a patch to add the hf tuning to OE-core?

In that case what tests should be performed before that and what (related)
tests are performed by the OE auto-builder?

BR // Mats



More information about the Openembedded-core mailing list