Clang emits the same debuginfo for `long double` and `__float128` on x86-64 and PowerPC despite them being different types

[beetrees]

On both non-Windows x86-64 (which uses x86_fp80 as long double) and PowerPC (which uses ppc_fp80 as long double), Clang emits long double and __float128 with exactly the same debuginfo: a DW_AT_encoding of DW_ATE_float and a DW_AT_byte_size of 0x10. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as long double is long double, meaning __float128 values get displayed as nonsense.

This can be seen by debugging this C program on an affected platform:

void breakpoint(long double ld, __float128 f128) {}

int main() {
    breakpoint(1.0, 2.0);
}

The long double will be displayed correctly in LLDB, whereas the __float128 will not. This problem also affects debuginfo emitted by GCC and rustc (while rustc doesn't support long double, its f128 type will still get misinterpreted as long double by the debugger).

While searching for previous discussion, I found this thread from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new DW_ATE codes, but I haven't been able to find any further discussion since.

[llvmbot]

@llvm/issue-subscribers-backend-powerpc

Author: None (beetrees)

On both non-Windows x86-64 (which uses `x86_fp80` as `long double`) and PowerPC (which uses `ppc_fp80` as `long double`), Clang emits `long double` and `__float128` with exactly the same debuginfo: a `DW_AT_encoding` of `DW_ATE_float` and a `DW_AT_byte_size` of `0x10`. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as `long double` is `long double`, meaning `__float128` values get displayed as nonsense. This can be seen by debugging this C program on an affected platform: ```c void breakpoint(long double ld, __float128 f128) {} int main() { breakpoint(1.0, 2.0); } ``` The `long double` will be displayed correctly in LLDB, whereas the `__float128` will not. This problem also affects debuginfo emitted by GCC and `rustc` (while `rustc` doesn't support `long double`, its `f128` type will still get misinterpreted as `long double` by the debugger). While searching for previous discussion, I found [this thread](https://lists.dwarfstd.org/pipermail/dwarf-discuss/2022-January/002103.html) from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new `DW_ATE` codes, but I haven't been able to find any further discussion since.

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: None (beetrees)

On both non-Windows x86-64 (which uses `x86_fp80` as `long double`) and PowerPC (which uses `ppc_fp80` as `long double`), Clang emits `long double` and `__float128` with exactly the same debuginfo: a `DW_AT_encoding` of `DW_ATE_float` and a `DW_AT_byte_size` of `0x10`. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as `long double` is `long double`, meaning `__float128` values get displayed as nonsense. This can be seen by debugging this C program on an affected platform: ```c void breakpoint(long double ld, __float128 f128) {} int main() { breakpoint(1.0, 2.0); } ``` The `long double` will be displayed correctly in LLDB, whereas the `__float128` will not. This problem also affects debuginfo emitted by GCC and `rustc` (while `rustc` doesn't support `long double`, its `f128` type will still get misinterpreted as `long double` by the debugger). While searching for previous discussion, I found [this thread](https://lists.dwarfstd.org/pipermail/dwarf-discuss/2022-January/002103.html) from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new `DW_ATE` codes, but I haven't been able to find any further discussion since.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: None (beetrees)

On both non-Windows x86-64 (which uses `x86_fp80` as `long double`) and PowerPC (which uses `ppc_fp80` as `long double`), Clang emits `long double` and `__float128` with exactly the same debuginfo: a `DW_AT_encoding` of `DW_ATE_float` and a `DW_AT_byte_size` of `0x10`. This means debuggers like LLDB can't tell the difference: currently LLDB will presume the float type that is the same size as `long double` is `long double`, meaning `__float128` values get displayed as nonsense. This can be seen by debugging this C program on an affected platform: ```c void breakpoint(long double ld, __float128 f128) {} int main() { breakpoint(1.0, 2.0); } ``` The `long double` will be displayed correctly in LLDB, whereas the `__float128` will not. This problem also affects debuginfo emitted by GCC and `rustc` (while `rustc` doesn't support `long double`, its `f128` type will still get misinterpreted as `long double` by the debugger). While searching for previous discussion, I found [this thread](https://lists.dwarfstd.org/pipermail/dwarf-discuss/2022-January/002103.html) from January 2022 on the dwarf-discuss mailing list that appeared to be leaning towards adding new `DW_ATE` codes, but I haven't been able to find any further discussion since.