From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130654 invoked by alias); 23 Mar 2017 20:23:22 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 130615 invoked by uid 89); 23 Mar 2017 20:23:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*r:ip*192.168.2.2, 4.4, H*i:sk:8a60b8b, H*f:sk:8a60b8b X-HELO: OARmail.OARCORP.com Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Mar 2017 20:23:20 +0000 Received: from [192.168.1.175] (192.168.1.175) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 23 Mar 2017 15:23:19 -0500 Subject: Re: newlib ieeefp.h again To: Craig Howland , "newlib@sourceware.org" References: <854be012-0f1f-b0bf-b7a8-bc615452fa0e@aps.anl.gov> <58D37229.70306@embedded-brains.de> <8a60b8b5-b92f-394c-3777-d89e207f0a0b@LGSInnovations.com> From: Joel Sherrill Message-ID: <5830e1d6-fe0a-9f56-1c78-46555b2d557e@oarcorp.com> Date: Thu, 23 Mar 2017 20:23:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8a60b8b5-b92f-394c-3777-d89e207f0a0b@LGSInnovations.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017/txt/msg00216.txt.bz2 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 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 >