mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Feasability of patching libm with OS X 10.5.8 libc for IBM double-double in PPC
Date: Wed, 6 Dec 2017 12:33:16 -0500	[thread overview]
Message-ID: <20171206173316.GV1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <CA+fZqCXK8ZH6hPk-2t9T2ZhBEW-xnfzfSvhHnCv3gDRx_B7mPA@mail.gmail.com>

On Wed, Dec 06, 2017 at 06:23:33PM +0100, ardi wrote:
> Hi!!
> 
> Disclaimer: I've read previous threads about long double support in
> musl, as well as web pages and I understand that musl won't support
> the IBM double-double, by design choice. I respect that decision (I've
> just started to use musl and I can only say I admire the quality and
> the design), and I'm not writing this as my opinion about that
> decision.
> 
> Said this, I need IBM double-double in PowerPC targets (using clang as
> compiler), and I'd like to use musl because of its well written code.
> 
> I'd also have the option of using the libc from OS X 10.5.8, which,
> AFAIK, is the latest libc from Apple with full support for PPC and
> PPC64 before they dropped them. This is libc 498.1.7 from the Apple
> open source site.
> 
> However, building Darwin components was never easy (build instructions
> are most of the times missing, ask the PureDarwin people), so I
> *believe* I can get this libc working, but who knows...
> 
> As a (perhaps) better solution, I thought that maybe I don't need to
> patch too many musl source files in order to get double-double
> working. If I'm understanding the situation correctly, the
> double-double implementation is actually generated by clang at compile
> code. The libc library should only need to provide the interface
> definitions (the definitions for mantissa bits, exponent bits, max
> values, etc...), and perhaps the implementation of some functions
> whose code wouldn't be generated by the compiler (not sure of this, as
> clang generates code for a set of functions through builtins in
> compiler_rt).
> 
> Maybe there would be some issues with converting floating point to
> char string, but it would depend on what code you'd use for that
> conversion.

The musl code for printing and parsing floating point numbers depends
on long double having IEEE semantics. It's a complete toss-up whether
it will work with formats like double-double that don't give IEEE
semantics. Aside from guaranteeing reasonable semantics that you can
reason about to programs using musl, this internal dependency is a
major reason why musl does not support weird long double formats.

> So, as a personal patch (not pushing for official support, as I said
> above), do you consider it would be feasible to patch the necessary
> musl source files with contents from the OS X 10.5.8 libc?

I don't think this solves the main problem (the dependency above) at
all; at best it just gives you math.h long-double functions that work
on double-double.

You could obviously modify vfprintf.c and __floatscan.c to work with
double instead of long double, avoiding the double-double issue, but
then %Lf and strtold functionality would not work.

It's possible that you get "lucky" and they happen to work (or work
well enough for you) with double-double as-is, but I would be really
skeptical of relying on that in situations where it matters.

> Do you believe it would be a matter of a reasonably small set of
> files, or rather an overwhelming task?
> 
> And... do you know of any confidence test I could run for checking
> that it's working as expected?

The libc-test math tests and printf/scanf type tests might be
sufficient to get some confidence that you didn't break normal float
and double stuff, but I'm not sure; you'd probably need to review what
they cover. I'm not aware of any tests that would help for
double-double testing.

Rich


  reply	other threads:[~2017-12-06 17:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-06 17:23 ardi
2017-12-06 17:33 ` Rich Felker [this message]
2017-12-06 17:53 ` Szabolcs Nagy
2017-12-06 19:33   ` ardi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171206173316.GV1627@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).