Re: newlib ieeefp.h again

[Craig Howland <howland at LGSInnovations dot com>]

On 03/24/2017 02:05 AM, Sebastian Huber wrote:
> On 23/03/17 21:05, Craig Howland wrote:
> > On 03/23/2017 02:58 AM, Sebastian Huber wrote:
> > > On 23/03/17 00:17, Andrew Johnson wrote:
> > > > 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:
> > >
> > > Yes, this definition of _LDBL_EQ_DBL is wrong, since it depends on the 
> > > multilib. For example we have in the GCC build tree:
> > >
> > > grep _LDBL_EQ_DBL `find -name newlib.h`
> > > ./m68k-rtems4.12/m68040/softfp/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> > > ...
> > >
> > > In the installation tree:
> > >
> > > grep _LDBL_EQ_DBL `find -name newlib.h`
> > > ./m68k-rtems4.12/include/newlib.h:/* #undef _LDBL_EQ_DBL */
> > >
> > > So, only one random newlib.h is copied to the installation tree, therefore 
> > > all newlib.h of the build tree must be identical.
> > >
> > > I would move the _LDBL_EQ_DBL definition to <ieeefp.h> based on compiler 
> > > provided defines.
> > The primary question is whether this is truly possible or not, which will 
> > depend upon both what compiler and how old of a compiler version newlib wants 
> > to support.  Back in 2009 when _LDBL_EQ_DBL was added to newlib.hin, this was 
> > not really possible as both float.h and compiler predefines were spotty. As 
> > long as we don't need to go back too many versions, it ought to be fine to do 
> > it at build time now.
> > Craig
>
> Does "spotty" mean they are broken or not available? Maybe we should
>
> 1. define _LDBL_EQ_DBL in <ieeefp.h> by means of compiler defines
>
> 2. fall back to define_LDBL_EQ_DBL via  a _HIGHLY_DANGEROUS_LDBL_EQ_DBL_HINT 
> defined via <newlib.h>
They were partially broken/not available in 2009, but today they ought to be 
fine.  That is, if Corinna and Jeff agree with Joel's take that people can use 
an old Newlib release if their compiler it too old, anything less than about 5 
years old (date based on my 4.4.7) looks fine.  Taking a quick look at what I'm 
using on current projects--GCC 4.4.7 native in RHEL6, 5.2.1 aarch64-none-elf-gcc 
and armr5-none-eabi-gcc cross, and 5.2.0 mb-gcc cross--all have the same 13 
defines for LDBL.

$ armr5-none-eabi-gcc -dM -E -c n.c | grep LDBL
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __LDBL_MAX_EXP__ 1024
#define __LDBL_HAS_INFINITY__ 1
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __LDBL_HAS_QUIET_NAN__ 1
#define __LDBL_HAS_DENORM__ 1
#define __LDBL_EPSILON__ 2.2204460492503131e-16L
#define __LDBL_MANT_DIG__ 53
#define __LDBL_MIN_EXP__ (-1021)
#define __LDBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L
#define __LDBL_MIN_10_EXP__ (-307)
#define __LDBL_DIG__ 15

Craig