* newlib ieeefp.h again
@ 2017-03-22 23:17 Andrew Johnson
2017-03-23 6:59 ` Sebastian Huber
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Johnson @ 2017-03-22 23:17 UTC (permalink / raw)
To: Joel Sherrill, howland; +Cc: newlib
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-22 23:17 newlib ieeefp.h again Andrew Johnson
@ 2017-03-23 6:59 ` Sebastian Huber
2017-03-23 16:19 ` Andrew Johnson
2017-03-23 20:05 ` Craig Howland
0 siblings, 2 replies; 9+ messages in thread
From: Sebastian Huber @ 2017-03-23 6:59 UTC (permalink / raw)
To: Andrew Johnson, Joel Sherrill, howland; +Cc: newlib
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 */
./m68k-rtems4.12/m68040/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/m5208/newlib/newlib.h:#define _LDBL_EQ_DBL 1
./m68k-rtems4.12/m5329/newlib/newlib.h:#define _LDBL_EQ_DBL 1
./m68k-rtems4.12/m5206/newlib/newlib.h:#define _LDBL_EQ_DBL 1
./m68k-rtems4.12/m5407/newlib/newlib.h:#define _LDBL_EQ_DBL 1
./m68k-rtems4.12/softfp/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/m68000/newlib/targ-include/newlib.h:/* #undef
_LDBL_EQ_DBL */
./m68k-rtems4.12/m68000/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/newlib/targ-include/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/m5475/softfp/newlib/newlib.h:#define _LDBL_EQ_DBL 1
./m68k-rtems4.12/m5475/newlib/newlib.h:#define _LDBL_EQ_DBL 1
./m68k-rtems4.12/m68060/softfp/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/m68060/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/mcpu32/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
./m68k-rtems4.12/m5307/newlib/newlib.h:#define _LDBL_EQ_DBL 1
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.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-23 6:59 ` Sebastian Huber
@ 2017-03-23 16:19 ` Andrew Johnson
2017-03-23 20:05 ` Craig Howland
1 sibling, 0 replies; 9+ messages in thread
From: Andrew Johnson @ 2017-03-23 16:19 UTC (permalink / raw)
To: Sebastian Huber, Joel Sherrill, howland; +Cc: newlib
On 03/23/2017 01:58 AM, Sebastian Huber wrote:
> On 23/03/17 00:17, Andrew Johnson wrote:
>> 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 */
> ./m68k-rtems4.12/m68040/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/m5208/newlib/newlib.h:#define _LDBL_EQ_DBL 1
> ./m68k-rtems4.12/m5329/newlib/newlib.h:#define _LDBL_EQ_DBL 1
> ./m68k-rtems4.12/m5206/newlib/newlib.h:#define _LDBL_EQ_DBL 1
> ./m68k-rtems4.12/m5407/newlib/newlib.h:#define _LDBL_EQ_DBL 1
> ./m68k-rtems4.12/softfp/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/m68000/newlib/targ-include/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/m68000/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/newlib/targ-include/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/m5475/softfp/newlib/newlib.h:#define _LDBL_EQ_DBL 1
> ./m68k-rtems4.12/m5475/newlib/newlib.h:#define _LDBL_EQ_DBL 1
> ./m68k-rtems4.12/m68060/softfp/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/m68060/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/mcpu32/newlib/newlib.h:/* #undef _LDBL_EQ_DBL */
> ./m68k-rtems4.12/m5307/newlib/newlib.h:#define _LDBL_EQ_DBL 1
Are there any other settings in those newlib.h files that change
depending on the multilib? I would suggest checking the other CPU
families too, better to fix any similar issues all at once...
- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-23 6:59 ` Sebastian Huber
2017-03-23 16:19 ` Andrew Johnson
@ 2017-03-23 20:05 ` Craig Howland
2017-03-23 20:23 ` Joel Sherrill
2017-03-24 6:05 ` Sebastian Huber
1 sibling, 2 replies; 9+ messages in thread
From: Craig Howland @ 2017-03-23 20:05 UTC (permalink / raw)
To: newlib
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-23 20:05 ` Craig Howland
@ 2017-03-23 20:23 ` Joel Sherrill
2017-03-23 20:59 ` Craig Howland
2017-03-24 6:05 ` Sebastian Huber
1 sibling, 1 reply; 9+ messages in thread
From: Joel Sherrill @ 2017-03-23 20:23 UTC (permalink / raw)
To: Craig Howland, newlib
On 3/23/2017 3:05 PM, 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.
The common answer to this type of question is to say that if they
are using old versions of gcc, they can also use old versions of
newlib.
If this is not an issue as recently as gcc say 4.4 or 4.5, that
is still very old. Do you recall a gcc version which couldn't be
detected at build time?
--joel
> Craig
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-23 20:23 ` Joel Sherrill
@ 2017-03-23 20:59 ` Craig Howland
2017-03-23 21:03 ` Joel Sherrill
0 siblings, 1 reply; 9+ messages in thread
From: Craig Howland @ 2017-03-23 20:59 UTC (permalink / raw)
To: Joel Sherrill, newlib
On 03/23/2017 04:23 PM, Joel Sherrill wrote:
>
>
> On 3/23/2017 3:05 PM, Craig Howland wrote:
>>
>>
>> On 03/23/2017 02:58 AM, Sebastian Huber wrote:
>>> ...
>>> 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.
>
> The common answer to this type of question is to say that if they
> are using old versions of gcc, they can also use old versions of
> newlib.
>
> If this is not an issue as recently as gcc say 4.4 or 4.5, that
> is still very old. Do you recall a gcc version which couldn't be
> detected at build time?
>
> --joel
At that time, I think I was using GCC 4.1 and 2.95 (both PowerPC cross
compiler--vendor toolsets mostly took pretty long to update versions back then).
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-23 20:59 ` Craig Howland
@ 2017-03-23 21:03 ` Joel Sherrill
0 siblings, 0 replies; 9+ messages in thread
From: Joel Sherrill @ 2017-03-23 21:03 UTC (permalink / raw)
To: Craig Howland, newlib
On 3/23/2017 3:59 PM, Craig Howland wrote:
>
>
> On 03/23/2017 04:23 PM, Joel Sherrill wrote:
>>
>>
>> On 3/23/2017 3:05 PM, Craig Howland wrote:
>>>
>>>
>>> On 03/23/2017 02:58 AM, Sebastian Huber wrote:
>>>> ...
>>>> 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.
>>
>> The common answer to this type of question is to say that if they
>> are using old versions of gcc, they can also use old versions of
>> newlib.
>>
>> If this is not an issue as recently as gcc say 4.4 or 4.5, that
>> is still very old. Do you recall a gcc version which couldn't be
>> detected at build time?
>>
>> --joel
> At that time, I think I was using GCC 4.1 and 2.95 (both PowerPC cross
> compiler--vendor toolsets mostly took pretty long to update versions back then).
>
That is very old. I was basing my "it's too old" on what was
included with RHEL/CentOS 6 and both of those are WAY older
than that.
Just my opinion but I don't see a need to worry about compilers
that old. 2.95 didn't even have c99 and I think the C++ was
pre-standardization. 4.1.2 was released in Feb 2007 so that's
over a decade old since the last release on the branch. I
think we can move along now. :)
It would be nice to hear from Corinna and Jeff though.
--joel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-23 20:05 ` Craig Howland
2017-03-23 20:23 ` Joel Sherrill
@ 2017-03-24 6:05 ` Sebastian Huber
2017-03-24 15:46 ` Craig Howland
1 sibling, 1 reply; 9+ messages in thread
From: Sebastian Huber @ 2017-03-24 6:05 UTC (permalink / raw)
To: Craig Howland, newlib
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>
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: newlib ieeefp.h again
2017-03-24 6:05 ` Sebastian Huber
@ 2017-03-24 15:46 ` Craig Howland
0 siblings, 0 replies; 9+ messages in thread
From: Craig Howland @ 2017-03-24 15:46 UTC (permalink / raw)
To: Sebastian Huber, newlib
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-03-24 15:46 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-22 23:17 newlib ieeefp.h again Andrew Johnson
2017-03-23 6:59 ` Sebastian Huber
2017-03-23 16:19 ` Andrew Johnson
2017-03-23 20:05 ` Craig Howland
2017-03-23 20:23 ` Joel Sherrill
2017-03-23 20:59 ` Craig Howland
2017-03-23 21:03 ` Joel Sherrill
2017-03-24 6:05 ` Sebastian Huber
2017-03-24 15:46 ` Craig Howland
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).