From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98409 invoked by alias); 22 Mar 2017 23:17:36 -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 98393 invoked by uid 89); 22 Mar 2017 23:17:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=edward, Edward, arguing, claim X-HELO: mailrelay.anl.gov Received: from mailrelay.anl.gov (HELO mailrelay.anl.gov) (130.202.101.22) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Mar 2017 23:17:34 +0000 Received: from mailgateway.anl.gov (mailgateway.anl.gov [130.202.101.28]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailrelay.anl.gov (Postfix) with ESMTPS id D06ED20019E for ; Wed, 22 Mar 2017 18:17:33 -0500 (CDT) Received: from hybrid-george.anl.gov (HELO GEORGE.anl.gov) ([146.137.81.15]) by mailgateway.anl.gov with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2017 18:17:33 -0500 Received: from tux.aps.anl.gov (146.137.81.4) by smtp.anl.gov (146.137.81.39) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 22 Mar 2017 18:17:33 -0500 To: Joel Sherrill , From: Andrew Johnson Subject: newlib ieeefp.h again CC: Message-ID: <854be012-0f1f-b0bf-b7a8-bc615452fa0e@aps.anl.gov> Date: Wed, 22 Mar 2017 23:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-SW-Source: 2017/txt/msg00211.txt.bz2 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 - #define __LDBL_MANT_DIG__ 53 > #define __DBL_MANT_DIG__ 53 > tux$ m68k-rtems4.12-gcc -dM -E - #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