[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