[uClibc]Kernel FPU emulation vs. -msoft-float?
Jon Loeliger
jdl at vivato.net
Thu Jun 12 18:55:25 UTC 2003
> That seems somewhat of a stretch. I don't see why an (ell) in
> the format string would cause a problem.
>
> One thing that does pop out at me though is that the format
> strings are identical in fred(). Since it works when the strings
> are different, perhaps the compiler is attempting to avoid storing
> two copies of the format string and generating bad code?
>
> Manuel
Hey, I confessed to grasping at straws earlier! :-)
So, I took your advice and started poking around with
the generated code, looking for some common sub-expression
elimination sorts of failures. One thing I noticed was
that my simple test case (no printing of FP numbers) failed
when compiled at -Os or -O2, but worked at -O1 or below.
Good: the compiler is suspect.
Bad: the compiler is suspect.
In fact, everything after the gcc1 build is suspect now.
I recompiled the known world (GCC 3.2.2, uClibc 0.9.19,
all tools and the entire toolchain, the 2.4.18 kernel,
and all the Root FS parts at -O1. Still no joy.
What are the known issues with 3.2.2 on a mipsel box?
Many, if you believe the GCC test reports.
How do I totally back off to a pure soft-float system now?
I can see uClibc's soft-float option by claiming there
is no FPU on the box. How do I get GCC to believe it
is configured _only_ for soft-float now?
Thanks,
jdl
More information about the uClibc
mailing list