From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13479 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: 32-bit double and long double Date: Mon, 26 Nov 2018 12:03:39 -0500 Message-ID: <20181126170339.GO23599@brightrain.aerifal.cx> References: <87va4j3lpr.fsf@southeast> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543251711 19903 195.159.176.226 (26 Nov 2018 17:01:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 17:01:51 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13495-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 26 18:01:47 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gRKGW-0004vW-17 for gllmg-musl@m.gmane.org; Mon, 26 Nov 2018 18:01:44 +0100 Original-Received: (qmail 13411 invoked by uid 550); 26 Nov 2018 17:03:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13392 invoked from network); 26 Nov 2018 17:03:52 -0000 Content-Disposition: inline In-Reply-To: <87va4j3lpr.fsf@southeast> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13479 Archived-At: On Mon, Nov 26, 2018 at 06:25:04PM +0300, Eugene Sharygin wrote: > Hi, > > We're using Musl on a platform where both float, double, and long double > are in IEEE-754 binary32 format, and I'm wondering if a patch that lifts > some of the assumptions made regarding widths of floating-point types > would be accepted. No, musl only supports (roughly) Annex-F conforming environments, with IEEE single and double and a long double type with IEEE-compatible semantics. Such patches won't be accepted upstream. Is there a reason your target is defining double in an unuseful and incompatible way rather than doing hard-single and soft-double? If you have any control over the choice of ABI, I think the latter makes a lot more sense. Rich > Here is the relevant excerpt from the documentation: > > > Floating-point formats are assumed to be IEEE-754 binary32 format for > > float and IEEE-754 binary64 for double. > > > > Supported long double formats: IEEE-754 binary64 (ld64) and x86 80 bit > > extended precision format (ld80) are fully supported and there is > > partial support for IEEE-754 binary128 (ld128). > > Eugene