From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13481 Path: news.gmane.org!.POSTED!not-for-mail From: Eugene Sharygin Newsgroups: gmane.linux.lib.musl.general Subject: Re: 32-bit double and long double Date: Mon, 26 Nov 2018 20:35:13 +0300 Message-ID: <7F0CB0A7-AC92-4372-BCD6-082E67D6B142@gmail.com> References: <87va4j3lpr.fsf@southeast> <20181126170339.GO23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----B5CFY5YHWF9XKSTCIOILYMKF3IG6BF" Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1543253604 7221 195.159.176.226 (26 Nov 2018 17:33:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 17:33:24 +0000 (UTC) User-Agent: K-9 Mail for Android To: musl@lists.openwall.com,Rich Felker Original-X-From: musl-return-13497-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 26 18:33:20 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 1gRKl6-0001lv-Il for gllmg-musl@m.gmane.org; Mon, 26 Nov 2018 18:33:20 +0100 Original-Received: (qmail 6056 invoked by uid 550); 26 Nov 2018 17:35:29 -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 6038 invoked from network); 26 Nov 2018 17:35:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=2aqongXa7SazrVHbL/++dxM/bvbe3yWmki6458puMjY=; b=EYbaOo8S58TL6Hm+qTwTwAi4tTQ2yaqiYBSsGnGWUjUL6zYVMBTLZs1q7232cG2gds JFEc7LMiZK+NYj/PD48SpdX6U+s/DZ6eut92sTzMiTjH2/U7RhwzhaXCM1apOkrSFlVk lZonnlsFE6dzHyh6IjEkHdxSVAYS53imAOfhrBD5Q/qWs3N2cXu2+eGUgh0QUsFo7kCj Ita8db+t/QIknBSh0fPXZ+CHTjvjubEM4kJwnM2m/TI91GCWtvVNhDm+eSdoAoIEkB7L 9O6FLg5PZAk4OqkLwO4sRJd9vR5poq8cHX5HqepDwD3yBShKkcsrlQIdbsxqvl+rO4d8 JIBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=2aqongXa7SazrVHbL/++dxM/bvbe3yWmki6458puMjY=; b=OsTgATRNFrHIIqcylFtEvBWM9IXpTd77cXCTsaInQx0AjpKE6Ht/fRs2EXaiblIAQy 5iAItgcxcRHi9OMO1xYeCebKqlVsAajSJuXigIAd91p+5yZuPLami2qHBMs6PDdMrOPs oVHOVJtyBHDCf/4exaXS6+NUPhYIIwRDp3AMoGUxeKkrgwj169dOzDRZDn4YfYAMnTR0 iAlXzzFPsQqWoLz5Q3w3EZQ0JeLV8lyMUI5drGDFmYTmsdHvYoXHRXfUyf6Ejefapa7g XTQ8Up/oJeOEUH1tL/akdfosdZjnYKZrfDvkOw8pOjs2fEbCxSirh1dPT1nnmi9yA8zL z3kw== X-Gm-Message-State: AA+aEWao3dfbMscMajur4oY9uJi3bXcTSvzKZm3rm5zP/Oez4PyKZs0e ksWN9yvhqilys52gfbHtenVnAa9M X-Google-Smtp-Source: AJdET5ezHfC2ThjGYwKmbLYjbC89PNcj/4gdGOz0PUZbb+xPkU1CH/4zbXCmkN2QcAUzughap1rMDw== X-Received: by 2002:a2e:145a:: with SMTP id 26-v6mr17394225lju.116.1543253716858; Mon, 26 Nov 2018 09:35:16 -0800 (PST) In-Reply-To: <20181126170339.GO23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13481 Archived-At: ------B5CFY5YHWF9XKSTCIOILYMKF3IG6BF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rich, On 26 November 2018 20:03:39 GMT+03:00, Rich Felker wr= ote: >On Mon, Nov 26, 2018 at 06:25:04PM +0300, Eugene Sharygin wrote: >> Hi, >>=20 >> 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=2E > >No, musl only supports (roughly) Annex-F conforming environments, with >IEEE single and double and a long double type with IEEE-compatible >semantics=2E Such patches won't be accepted upstream=2E > >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=2E I guess it does=2E The platform is very memory constrained though, so we'l= l have to evaluate first=2E Thank you for suggestion! Eugene >> Here is the relevant excerpt from the documentation: >>=20 >> > Floating-point formats are assumed to be IEEE-754 binary32 format >for >> > float and IEEE-754 binary64 for double=2E >> > >> > 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)=2E ------B5CFY5YHWF9XKSTCIOILYMKF3IG6BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rich,

On 26 November 2018 20:03:39 GMT+03:00, Rich Felker <dal= ias@libc=2Eorg> wrote:
>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 flo= ating-point types
>> would be accepted=2E
>
>No, musl = only supports (roughly) Annex-F conforming environments, with
>IEEE s= ingle and double and a long double type with IEEE-compatible
>semanti= cs=2E Such patches won't be accepted upstream=2E
>
>Is there a = reason your target is defining double in an unuseful and
>incompatibl= e 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=2E

I guess it does=2E The platform is very memory constrained= though, so we'll
have to evaluate first=2E

Thank you for suggest= ion!

Eugene

>> Here is the relevant excerpt from the do= cumentation:
>>
>> > Floating-point formats are assum= ed to be IEEE-754 binary32 format
>for
>> > float and IEE= E-754 binary64 for double=2E
>> >
>> > Supported lo= ng double formats: IEEE-754 binary64 (ld64) and x86 80
>bit
>&g= t; > extended precision format (ld80) are fully supported and there is>> > partial support for IEEE-754 binary128 (ld128)=2E
------B5CFY5YHWF9XKSTCIOILYMKF3IG6BF--