[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181127023211.GR23599@brightrain.aerifal.cx>
Date: Mon, 26 Nov 2018 21:32:11 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: 32-bit double and long double
On Mon, Nov 26, 2018 at 05:36:58PM +0000, Jon Chesterfield wrote:
> >
> > 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.
> >
>
> I can see a few arguments for float==double, but haven't actually done that
> for our target yet.
>
> A common error is to write 1.0 instead of 1.0f, where the former sometimes
> pulls in the soft double support.
I think gcc has a language-variant option to make floating point
constants float by default rather than double, but this is probably a
bad idea. Better would be just setting up your tooling to catch
inadvertent use of double where it's not wanted/needed.
> Integer arguments to libm functions promote to double but I would prefer
> promote to 32 bit float.
This is only the case if you're calling the functions that take double
arguments. If you call the float ones, promotion is just to float.
It's your choice which you use.
> Arguments to variadic functions promote to double. Again I would prefer 32
> bit float.
Indeed this is a hard limitation of the language. I suppose it comes
in mostly/only for passing floating point values to printf. The
promotion should at least be nothing more than a few 64-bit shift/or
ops.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
