Mangling _FloatN types about cxx-abi HOT 7 OPEN

Is _Float16 the same as __fp16, which already supported on some architectures? If so, should the two types be the same?

And if so, please remember there may already be code that uses __fp16 in mangled contexts, using mangling "Dh".

$ clang -target aarch64-linux -O2 -S -o - -xc++ - <<<'void f(const __fp16 &) {}' 
        .text
        .file   "-"
        .globl  _Z1fRKDh                // -- Begin function _Z1fRKDh
        .p2align        2
        .type   _Z1fRKDh,@function
_Z1fRKDh:                               // @_Z1fRKDh
// BB#0:
        ret
.Lfunc_end0:
        .size   _Z1fRKDh, .Lfunc_end0-_Z1fRKDh
                                        // -- End function

        .ident  "openSUSE Linux clang version 5.0.0 (trunk 307005) (based on LLVM 5.0.0)"
        .section        ".note.GNU-stack","",@progbits

PS: __float128 is also already mangled as "g"

from cxx-abi.

No, they are really different types: __fp16 is a storage-only type (arithmetic is performed in single precision, the result truncated and stored in half precision), and _Float16 is a "native" type with arithmetic in half precision. As they are different types with different semantics, they should be mangled differently.

from cxx-abi.

If TS 18661 considers them different types, then the C++ ABI should provide new manglings for them unless we have some compelling reason to reject ever using that extension in C++, which seems unlikely. I would recommend:

   <builtin-type> ::= 'DF' <number> '_'      # ISO/IEC TS 18661 _FloatN

Would you mind submitting a pull request?

from cxx-abi.

Many thanks and yes, I will start preparing a patch.

from cxx-abi.

That patch is #22, for the record.

from cxx-abi.

Patch approved. Thanks!

from cxx-abi.

@smeijer1234 Are you aware of any implementations that currently use this mangling? The Clang folks are uncertain whether it was intended to not make these manglings substitution candidates. If we're bound by ABI compatibility for them, then so be it, but if we added this as a forward-looking change and are just now introducing implementations that use it, maybe we can still allow these to be substituted.

from cxx-abi.