From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13480 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:30:15 +0300 Message-ID: <0636B256-7273-432C-8077-8824E0453698@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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1543253354 14969 195.159.176.226 (26 Nov 2018 17:29:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Nov 2018 17:29:14 +0000 (UTC) User-Agent: K-9 Mail for Android To: musl@lists.openwall.com,Rich Felker Original-X-From: musl-return-13496-gllmg-musl=m.gmane.org@lists.openwall.com Mon Nov 26 18:29:10 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 1gRKh2-0003jW-TI for gllmg-musl@m.gmane.org; Mon, 26 Nov 2018 18:29:09 +0100 Original-Received: (qmail 1358 invoked by uid 550); 26 Nov 2018 17:31:17 -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 1339 invoked from network); 26 Nov 2018 17:31:17 -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=q3udY0H16pIBh0kYyd1ekN2U5LTwgZYxGn2a0WPaN+o=; b=HaRYQpelyeRNlrO8j+oyv3kBxwDPm58MzaaWxVDcXQone2B33FYFMix8+NODEvBEfe DEHPvPJ9RBsFJPmZc+zmCp1PakTGMknPGjYY1ODW+YBT86o0G/Ez1DZlfbJcObqCABYN 22Y7KEyQoaaFZx54OmDzvQBZ5xD/IaYhujlhlFjkEOqzczlrRuPUeHS3f5dsyRUFKYVD ZBacHx4JHFz1P76Oqhr/Zo1F1I+GqB5NJd0LqYxXyrQMM51eIboL9IVH4geXA3x2WZx9 pf3oJDG1BoNXqp2HLN0Q6Fb4uy985RuNnCGbGB920tvUndB/srzObxwIBruWTxtXfWIq Bt+w== 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=q3udY0H16pIBh0kYyd1ekN2U5LTwgZYxGn2a0WPaN+o=; b=EA0Lt4pzz71eNX8BuPnnzldosFTtALE27BWoek1hTRt/ehE5TM/bx9uj0N9f188FKi 3yi51GjmEGeTu3ZnJY72KByucJO2+dlaXdkyxFFO6shA7Xu/hE2mdp7TFWsqq+vurjwB BU0qsks0hinBgtVi5+pBR2KkjN4ISDKn16A8/eenluvE8ZfJp+Zf4DIZVZf/86fNSgAB uBRpRH1pqsMGhQH5n1YeE0F0JXhydxRuh5nSrEQEigD2cbVjNYqQuEXMqLP920NOHECx QjAKkPhgKjqVJW7D6U1B3joIAnbQlyZBlwKbIodXxL3CqtfBHp+lmOnvKQyn5rHtAS38 nEMA== X-Gm-Message-State: AA+aEWa+ZD3qAgr4Sr2C8GHKcrBIjgHoWCzDTpqpN2fI4bEuyvWfDtry r8OO38ntvRz5uQDSaSg6YiRQPrOb X-Google-Smtp-Source: AFSGD/VDbPFCAq1fb7K7UoE1Hl6BH3KY6jC4UrCyDH4gXwzfrV76JVXoB40hQDPIVARuVjQCy6zQIA== X-Received: by 2002:a2e:45d:: with SMTP id 90-v6mr17803740lje.110.1543253465112; Mon, 26 Nov 2018 09:31:05 -0800 (PST) In-Reply-To: <20181126170339.GO23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13480 Archived-At: 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