mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: long double on powerpc64
Date: Thu, 10 Mar 2016 23:17:59 -0500	[thread overview]
Message-ID: <20160311041759.GU9349@brightrain.aerifal.cx> (raw)
In-Reply-To: <20160311031636.GA3851@gordon.members.linode.com>

On Thu, Mar 10, 2016 at 09:16:36PM -0600, Bobby Bingham wrote:
> I've been working on a PPC64 port of musl lately.  I've made some good
> progress, and it's time to decide what to do about the long double type.
> 
> The PPC64 ELFv2 ABI [1] calls for a 128 bit long double.  It allows an
> implementation to choose to use either IEEE quad, or IBM double double,
> with IEEE quad being preferred.
> 
> On the compiler side, it looks like things are a bit of a mess.
> 
> Clang only supports IBM double double on PPC64, AFAICS, and therefore
> won't work for us currently.
> 
> GCC support is more complicated.  It supports both 128 bit variants, as
> well as supporting (and defaulting to) a 64 bit long double.  To get a
> 128 bit long double, you must build gcc with --with-long-double-128 or
> pass -mlong-double-128, and even then you get IBM double double.  To get
> IEEE quad, you must additionally pass -mlong-double-128, though there
> are whispers that the default may change in gcc 7 [2].
> 
> The final piece of bad news is that gcc can't successfully build musl on
> PPC64 with IEEE quad long double.  It chokes on even trivial code using
> long double complex [3].  So only 64 bit long double is usable for now.
> 
> The good news is that gcc's predefined macros are sufficient to detect
> which long double variant is in use.  My current thinking is that we can
> support both 64 bit long and IEEE quad as two powerpc64 subarchs, even
> if we can only implement 64 bit for now.  Because it looks like the
> future direction is for IEEE quad to become the default, I think that
> should be the suffix-less subarch, and the 64 bit long double subarch
> should have a -ld64 suffix or similar.

My leaning would be to just go with ld64 if nobody has their act
together for quad support, but let's see what people who want to use
powerpc64 think about it. The only option that's not on the table is
IBM double-double (because it's incompatible with musl's assumption of
IEEE semantics; math-savvy people in the musl community already know
this of course but I'm repeating it for the sake of possible
newcomers).

Thanks for digging up this information.

Rich


  reply	other threads:[~2016-03-11  4:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-11  3:16 Bobby Bingham
2016-03-11  4:17 ` Rich Felker [this message]
2016-03-11 11:19   ` Justin Cormack
2016-03-11 13:04     ` Szabolcs Nagy
2016-03-11 15:55       ` Rich Felker
2016-03-11 16:38         ` Szabolcs Nagy
2016-03-14 20:13       ` Bobby Bingham

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=20160311041759.GU9349@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).