On Jun 12, 2013, at 9:27 AM, Matthew Dempsky <[email protected]> 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 <[email protected]> wrote: >> On Jun 11, 2013, at 2:18 AM, Matthew Dempsky <[email protected]> wrote: >>> On Mon, Jun 10, 2013 at 10:40 PM, Dennis Handly <[email protected]> wrote: >>>>> From: Matthew Dempsky <[email protected]> >>>>> 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. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
