From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47100 invoked by alias); 24 Mar 2017 06:05:45 -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 30932 invoked by uid 89); 24 Mar 2017 06:05:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: Yes, score=6.3 required=5.0 tests=AWL,BAYES_50,FOREIGN_BODY,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=no version=3.3.2 spammy=brains, D*embedded-brains.de, keine, diese X-HELO: dedi548.your-server.de Received: from dedi548.your-server.de (HELO dedi548.your-server.de) (85.10.215.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Mar 2017 06:05:05 +0000 Received: from [78.47.166.52] (helo=sslproxy04.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1crILQ-0003ns-1n; Fri, 24 Mar 2017 07:05:04 +0100 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy04.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1crILP-0006CH-PR; Fri, 24 Mar 2017 07:05:03 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 7D77B2A1663; Fri, 24 Mar 2017 07:05:32 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id at1fQ3n3j8x4; Fri, 24 Mar 2017 07:05:30 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 3E4A52A1664; Fri, 24 Mar 2017 07:05:30 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uMW0apvCN0Fg; Fri, 24 Mar 2017 07:05:30 +0100 (CET) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 2BC5B2A1663; Fri, 24 Mar 2017 07:05:30 +0100 (CET) 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: Sebastian Huber Message-ID: <58D4B70C.7060200@embedded-brains.de> Date: Fri, 24 Mar 2017 06:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.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: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00219.txt.bz2 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=20 >>> the >>> result. I think I can explain what's happening. >>> >>> Newlib's setting for _LDBL_EQ_DBL (in newlib.h) needs to change=20 >>> 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=20 >> 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,=20 >> therefore all newlib.h of the build tree must be identical. >> >> I would move the _LDBL_EQ_DBL definition to based on=20 >> compiler provided defines. >> > The primary question is whether this is truly possible or not, which=20 > will depend upon both what compiler and how old of a compiler version=20 > newlib wants to support. Back in 2009 when _LDBL_EQ_DBL was added to=20 > newlib.hin, this was not really possible as both float.h and compiler=20 > predefines were spotty. As long as we don't need to go back too many=20 > 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 by means of compiler defines 2. fall back to define_LDBL_EQ_DBL via a=20 _HIGHLY_DANGEROUS_LDBL_EQ_DBL_HINT defined via --=20 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=C3=A4ftliche Mitteilung im Sinne des EHUG.