From: Craig Howland <howland@LGSInnovations.com>
To: <newlib@sourceware.org>
Subject: Re: newlib ieeefp.h again
Date: Thu, 23 Mar 2017 20:05:00 -0000 [thread overview]
Message-ID: <8a60b8b5-b92f-394c-3777-d89e207f0a0b@LGSInnovations.com> (raw)
In-Reply-To: <58D37229.70306@embedded-brains.de>
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
next prev parent reply other threads:[~2017-03-23 20:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 23:17 Andrew Johnson
2017-03-23 6:59 ` Sebastian Huber
2017-03-23 16:19 ` Andrew Johnson
2017-03-23 20:05 ` Craig Howland [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a60b8b5-b92f-394c-3777-d89e207f0a0b@LGSInnovations.com \
--to=howland@lgsinnovations.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).