<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/92081>92081</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            llvm-cxxfilt assumes that the host's representation for floating point types matches the target's
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            tools:llvm-cxxfilt
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          bd1976bris
      </td>
    </tr>
</table>

<pre>
    **Preamble:**
Consider the following code:

```
namespace cxx20 {
  template<auto> struct A {};
  void f(A<1.0l>) {}
};
```

For the above Clang mangles `cxx20::f(cxx20::A<0x8p-3L>)` mangles as `_ZN5cxx201fENS_1AILe3fff8000000000000000EEE`. Note that GCC mangles as `_ZN5cxx201fENS_1AILe0000000000003fff8000000000000000EEE` -  the leading zeros are apparently a benign difference.

The `1AILe3fff8000000000000000E` part (for `A < 1.0l >`) is mangled as:

```
1AI      L          e             3fff8000000000000000    E
¦        ¦          ¦             ¦                       ¦
name     literal    long double   hexadecimal string      literal-bookend
```

Where the hexadecimal string is the in memory bytes on the target. Quoting from the Itanium-ABI:

> Floating-point literals are encoded using a fixed-length lowercase hexadecimal string corresponding to the internal representation, high-order bytes first. For example: "Lf bf800000 E" is -1.0f on platforms conforming to IEEE 754.

Clang uses 20 hex characters to encode a long double on most Itanium-ABI targets including PS5 (long double is implemented as 80-bit extended precision).

**Problem:**
With host = windows (long double is an alias for double) and target = PS5 (long double is 80-bit extended precision) ASAN reports a stack-buffer-overflow when running `llvm-cxxfilt.exe _ZN5cxx201fENS_1AILe3fff8000000000000000EEE`.

This occurs because the demangler code assumes that the representation of a floating point number on the target matches the representation on the host. See: https://github.com/llvm/llvm-project/blob/023cdfcc1a5bdef7f12bb6da9328f93b477c38b8/llvm/include/llvm/Demangle/ItaniumDemangle.h#L2558 However, Visual Studio on the windows host implements long double as synonym for double. Therefore, there isn't enough space to unpack into and the implementation overflows the 8 bytes for a long double and triggers the ASAN fault. Without ASAN, the number is decoded incorrectly. Similar problems will affect other cross-compiler demangling scenarios where there is a difference in the floating point representation between the target and host.

**Ideas for fixes:**
We could simply print the hexadecimal string from the mangled name, this appears to be what GNU implements: GNU cxxfilt demangles  `_ZN5cxx201fENS_1AILe3fff8000000000000000EEE` as `cxx20::f(cxx20::A<(long double)[3fff8000000000000000]>)`.
 If we just printed the mangled hexadecimal string then that would also remove the non-functional differences between the Windows and Linux output with cxxfilt for floating point literals, due to snprintf differences on different platforms.

We could use a target/host agnostic floating point decoder e.g. ADT/APFloat  - which could make some reasonable assumptions e.g. IEEE 754 representation. We might also provide a way of specifying the target for llvm-cxxfilt.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUV1tv2zzS_jXMzcCCTEU-XPjCdezvCxAEXaS7BfbmBUWNJL6lSIGkYnt__WIoObFct9gKgWPxMJzD8zxDC-9VbRA3LP_C8qcH0YfGuk1RztfLReGUfyhsed4wvmV8-9WhaAuNLNsOAyx9Yul2Z41XJToIDUJltbZHZWqQtowr45rxc5GOf_HViBZ9JySCPJ14Cmz5ZZgACNh2WgRk2U70wbJsDz64XgbYxmXLJ5Z9LH63qoSK8dWWZbt5kmqW7RlfXxYOR1_tuHFj-DzYIQBR2HeEnRamhlaYWqMHtkijhxROtqWTrl7p0PS06mbZy3AuW6QfO0Xc_Ne_X_O4Y17tX9_-mm-fXzCrqmqVTp_9fs8WaQKvNiCERgT4v93uf7B1bePXdmEGMUKNoqQC_Qed9SAcgug64dAEfQYBBRpVGyhVVaFDIzG5TtO3BsmLX4dAB3XCBWB8VVlHi7fAsh1QYYAytEipOMqPgZUg_O9xMt8-Q3xe4ONBuH7ueULj-9HejrPt4rJ4-vbz-_2h28lPCMdBrQI6oeNXa2oobV9ommrwJEqUqhWaIEyJv94wK6z9gab8DTK_N-gwVu6OLeXjjDLQYmvdGYpzQA_WxOEgXI0hgX_0NtDqytk2TjwHYVTfzrZfnm9zn-3hoK2g9bPOKhMurg5YQUPELqH3ZFBApU5YzjSaOjSg7RGdFP6uq9I6h76zJqIv2NHxgM4IDQ47hx5NEEFZw_gOGlU3M-tIWYagKuV8SICYiifRdlGJgHH-UkEx1h_2jHPKymyepBXlgXSksq71IK2hL-Ppz_v9Hpb54wTeA-97jx54SkGAbIQTMqDztGmIHsSkyNZAa324TuqYeQ_KSN3HgL--5cSJ643Kg6IwWjQh8gBW6axQAfAU0FCWO4dS-ZiQ9cTRiyLbQmN7I8jfVWigIY9Y9gRHZUp79HfOFgaEVsID8XQYJmYKU47ux_33_f6do7B9275SQa0LHgT4IOSPWdGToMzsO7pK2yMcGzTgemMoOWyRav3ezuTpVCkdEjwh_KFqTlVKebBS9s5DgVL0fiBQiYPmOBjK6H3foh-kluanIARbEcBHMsBABtO3BbopwaAVQTbo79oYFlI5EnjDCNkmhC5qHj8wfqhVaPoikbZl_EBZGP_NOmf_RhkYPxTaFowfUp7JspJyLvKixGpZzXlRLEqxzviqWmfF43Ips1Wx-rQzwA8_B57GDDB-GOF6GUkaxrMXnucr-H97xHd0RMJ_Kd8LDW-hL5W9BHOBVMTYB4L9hBTCgz8ba87tFbwS-EZiVlmHZDxEZVPeML4MgMb2dQPDjSBY6E0n5A9SCDtgkuTictiY3BFMQ-ZXF52w7oahcbtTdR1p3OCA0Er0OiRAdLF9iGOjV5cqKw8lDnqnTNQvGfQ5gTfVKi0cdAP_PByV1iCqCmUAS2GBdNb7mbRtpwhvI_IIR16iEU5ZTxQYlN0NfLxquqTo8T41Rd8NuAoMR8QJFCnUCLaf1eK5xJHsJNr-VjUQpO11CZ6SfIbO0YG_aDsfjeTSw6kRDsmjQLoOxSCYBcIxXmRe_3mFFCIBjYx0_-Clhz-_Lo33ot9f0KYCRpe0_Ms9kyx_-rjEjRmE5wqOCH_3Pgw5wXIS-Z3shCbWRAQ4xowK7S04bOlmGdFlzazqjaQaCn1VdT-p6PeRZlTSF2X6E9g-dH2AIwn8JXexnlOUXBo2FaTsI5m8ib5Xk8Ps5zUvfPbJCXI-UEESKkaQMX6I1Be1sT4oeXv-wBkHmNQJbJ--MX7Yfo2XCoAZHBslm9FqK34geNuSbApvjRikw_dtR8nxg4lLq76BfwLfEVpVN2HIcOfsu4rd-SjOJN6-Q6mq81iSC0MoYZNm81BusnKdrcUDbubLeb5Y5nzJH5pNlpfy8XG5xLlYllhimS_zLC1lXolsXaTZg9rwlD-m-fwxXfFlzhORYrVeIearVSVXec4eU2yF0gkdmFhXPyjve9ysebqaP2hRoPbxtxfnwVpNxLh2jXFOv8rcJg4Wfe3ZY6qVD_7TYFBB4-Z61899jarF-NLf6scd7IRzh37S0C41X_qH3unNHzevGLFn_BCD_m8AAAD__5bMpzg">