[cxx-abi-dev] Clarification about mangling floating point literals

[John McCall]

On Jun 12, 2013, at 9:27 AM, Matthew Dempsky <matthew at dempsky.org> wrote:
> Ah, thanks for the background, Mike!
> 
> What needs to be done then to ensure the document gets updated?
> Should I file a proper bug report somewhere?

No, reporting it here should be sufficient, optionally plus badgering
me a bit.  It's fixed now.

> On Tue, Jun 11, 2013 at 5:31 AM, Mike Herrick <mjh at edg.com> wrote:
>> On Jun 11, 2013, at 2:18 AM, Matthew Dempsky <matthew at dempsky.org> wrote:
>>> On Mon, Jun 10, 2013 at 10:40 PM, Dennis Handly <dhandly at cup.hp.com> wrote:
>>>>> From: Matthew Dempsky <matthew at dempsky.org>
>>>>> Can someone please clarify for me how floating-point literals can be
>>>>> encoded as a "fixed-length" string but "without leading zeros"?  E.g.,
>>>>> how should 0.0f be encoded?
>>>> 
>>>> I would assume you remove all but the only zero nibble.
>>>> I.e. The last zero isn't leading.
>>> 
>>> For what it's worth, GCC 4.6.3 and Clang 3.2 when targeting
>>> x86_64-linux-gnu both mangle 0.0f as Lf00000000E.
>>> 
>>> (But Clang 3.2 mangles 0.0l as Le3fff8000000000000000E, whereas GCC
>>> 4.6.3 mangles it as Le0000000000003fff8000000000000000E.  I don't have
>>> newer versions readily available to check.)

(That's 1.0L.)

Interesting;  I guess we need to rule on that.  As far as I know, this situation
is unique to x87 long doubles.  Clang is mangling the abstract long double
value representation, whereas GCC is mangling the contents of a long double
object in memory, including its tail padding.

(Just in case anybody isn't aware:  on x87 Unix-ish platforms, 'long double'
is usually the x87 native 80-bit IEEE format.  Loads and stores from the
floating-point stack really do load and store 10-byte chunks.  The processor
does not enforce alignment on these accesses, but nonetheless It is common
for alignof(long double) to exceed 2;  here it is 16, which dynamically ensures
that the access doesn't cross cache lines but which also adds 6 bytes of tail
padding.  Since x86 is little-endian, these padding bytes are being treated as
high-order.)

I think Clang's interpretation is pretty clearly the right one; literals are r-values,
and their "internal representation" should be the representation of an abstract
value.  Also, the padding bytes will always be zero and so contribute
absolutely nothing.

John.