does soft-float work?

does soft-float work?

[Jim Reekes]

I've copied a few lines of code that work as I would expect, expect with
I add the -soft-float option or -mcpu=823. I'm building with a YellowDog
release on a G3 PowerMac, where I removed EGCS and installed GCC
2.95.1-1e. I also have glibc 2.1.1-6h. But, I've also built this with a
clean install of YellowDog on a different PowerMac which included
egcs-2.91.66. There I get incorrect but different results. I've also put
the executable onto our 823 board, and it also gives different yet
incorrect results.

So I'm stumped. Does this float emulation package work? Here's what I do
know.

* printf with a float always fails.

* gdb shows that "i" and "f" are always correct.

* the assignment of "d" from "i" is correct

* the result of pow() returns 9.1981921218154364e-232

* here's the console output

float number (should be 4.000000): -0.000000
int cast of float (should be 4): 4
float number (should be 16.000000): 0.000000
int cast of double (should be 16): 0



  gcc -g -lm -msoft-float mathtest.c

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <math.h>

main(int ac, char **av)
{
  float   f;
  double  d;
  int     i;

  i = 2;
	
  f = (float)i;
  f *= f;
  printf("float number (should be 4.000000): %f\n", f);
  printf("int cast of float (should be 4): %d\n", (int)f);

  d = (double)i;
  d = pow(d, f);
  printf("float number (should be 16.000000): %f\n", d);
  printf("int cast of double (should be 16): %d\n", (int)d);
}

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: does soft-float work?

[Dan Malek]

Jim Reekes wrote:


> I add the -soft-float option or -mcpu=823.


I didn't know 823 was an option.  I thought all that was
supported was 821 and 860....Doesn't matter, it should simply
be 8xx anyway.



>   gcc -g -lm -msoft-float mathtest.c


Well, now...that -lm looks a little suspicious.  The
libary was probably compiled with hardware floating point
assumed (unless you built your own).

I also remember speaking to someone that found a varargs
and software floating point combination bug.....let me
try and track that down.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: does soft-float work?

[Stuart Adams]

We saw similar problems and found that there was a compiler
bug which emitted bad code when using varargs to pass doubles.

This only occurred when using -mcpu=8xx not with -msoft-float.

For example the following code did not work with egcs-1.1 when using
-mcpu=8xx

------
  #include <stdarg.h>

  double d = 500.0;

  vtst(char *fmt, ...) {
   double z;
   va_list ap;
   va_start(ap,fmt);
   z = va_arg(ap,double);
   printf("vatst=%d\n",(int)z);  // should print 500
 }


 main() {
   vtst("jj",d);
 }
------

I have not tried gcc 2.95.X so the bug may have been fixed.

The problem with printf is that libc was probably compiled with
-mcpu=8xx with a version of gcc with this bug. (libc/printf uses varags
to pass doubles internally) We recompiled libc with -msoft-float
and now things work fine.

-- Stuart

------------------------------------- 

Stuart Adams
Bright Star Engineering Inc.
19 Enfield Drive
Andover MA 01810 USA
Tel: +1-978-470-8738
Fax: +1-978-470-8878
Email: sja@brightstareng.com
Web: http://www.brightstareng.com/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: does soft-float work?

[Marcus Sundberg]

Dan Malek <dan@netx4.com> writes:

> I also remember speaking to someone that found a varargs
> and software floating point combination bug.....let me
> try and track that down.

Well, I know of one such bug in gcc:
I built gcc with --nfp/--without-fpu (don't remember what gcc calls
it) and --with-cpu=860. This causes the compiler to generate
software floating point code by default (in fact it doesn't seem to
be able to generate FPU instructions even with -mhard-float).
However, it does _not_ cause the specs file to define -D_SOFT_FLOAT
for the pre-processor by default.

This means that the caller passes fp arguments in soft-float syntax,
while the va_* macros tries to read them out in hard-float syntax.

The same problem may very well occur if you pass the compiler
-mcpu=860 but not -msoft-float. I'm not sure how to fix this
properly - here I just changed the specs file as I never compile
for PPCs with FPU.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: does soft-float work?

[Marcus Sundberg]

Stuart Adams <sja@brightstareng.com> writes:

> We saw similar problems and found that there was a compiler
> bug which emitted bad code when using varargs to pass doubles.
> 
> This only occurred when using -mcpu=8xx not with -msoft-float.
> 
> For example the following code did not work with egcs-1.1 when using
> -mcpu=8xx
> 
> ------
>   #include <stdarg.h>
> 
>   double d = 500.0;
> 
>   vtst(char *fmt, ...) {
>    double z;
>    va_list ap;
>    va_start(ap,fmt);
>    z = va_arg(ap,double);
>    printf("vatst=%d\n",(int)z);  // should print 500
>  }
> 
> 
>  main() {
>    vtst("jj",d);
>  }
> ------
> 
> I have not tried gcc 2.95.X so the bug may have been fixed.

Not fixed as of 2.95.1 at least.

> The problem with printf is that libc was probably compiled with
> -mcpu=8xx with a version of gcc with this bug. (libc/printf uses varags
> to pass doubles internally) We recompiled libc with -msoft-float
> and now things work fine.

The bug is in the installed specs file that gcc uses, not in the
compiler itself. See my other mail for details.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/