newlib ieeefp.h again

[Andrew Johnson]

Hi Joel & Craig,

Hopefully you remember this email conversation from November:

https://sourceware.org/ml/newlib/2016/msg01117.html

I just built the RTEMS master branch for the uC5282 BSP, and found the
same problem with the ieeefp.h header when building EPICS Base using the
result. I think I can explain what's happening.

Newlib's setting for _LDBL_EQ_DBL (in newlib.h) needs to change based on
the particular CPU being compiled for. Here's some evidence:

> tux$ m68k-rtems4.12-gcc -mcpu=5282 -dM -E - </dev/null | grep DBL_MANT_DIG
> #define __LDBL_MANT_DIG__ 53
> #define __DBL_MANT_DIG__ 53

> tux$ m68k-rtems4.12-gcc -dM -E - </dev/null | grep DBL_MANT_DIG
> #define __LDBL_MANT_DIG__ 64
> #define __DBL_MANT_DIG__ 53

When gcc is compiling for the 5282 CPU the double and long double types
are the same size, but for gcc's default m68k CPU they are different.
Presumably newlib was configured using the default CPU (I used the
standard rtems-source-builder, whatever that does), but that gives the
wrong setting when building for the uC5282.

I hand-edited my newlib.h file to look like this

> /* True if long double supported and it is equal to double.  */
> #if __LDBL_MANT_DIG__ == __DBL_MANT_DIG__
> #  define _LDBL_EQ_DBL 1
> #endif

and the result now successfully compiles the EPICS Base source file that
includes the ieeefp.h header.

Hopefully you can work out what the correct solution is to this issue,
I'm not sure myself whether the fix should be in RTEMS or in Newlib.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon