x86-64 Android: long double is binary128 but has no lowering — any long double signature, arithmetic, static initializer or variadic use is refused

[davidgmbb]

This is the x86-64 counterpart of #72; #1720 fixes the AArch64 side.

Observed

Since #761, buster models x86-64 Android long double as IEEE binary128, matching Clang: __LDBL_MANT_DIG__ is 113 and sizeof(long double) is 16. There is no lowering for that format on x86-64, though, so every use beyond declaring one is refused:

$ build/Release/ide cc -c -target x86_64-linux-android f.c
long double f(long double a, long double b) { return a + b; }
  -> C IR lowering does not yet support the parameter or return value types of function 'f'
double f(double x) { long double y = x; return (double)(y * 2); }
  -> C IR lowering does not yet support wide floating-point arithmetic
static long double k = 1.5L;
  -> C IR lowering: cannot fold '1.5L' in a static initializer
printf("%Lf", (long double)x);
  -> C IR lowering does not yet support the parameter or return value types of function 'printf'

For reference, clang --target=x86_64-linux-android passes binary128 in XMM registers (SSE class, one register per value) and lowers a + b to call __addtf3.

A stale comment compounds this. c_ir_target_supports_f80 in src/buster/lib/compiler/frontend/c/c_gen.c still says x86-64 Android "deliberately shares" the 80-bit System V long double. The data layout says binary128, and that predicate correctly returns false.

Expected

x86-64 Android long double works like AArch64 after #1720, matching Clang's objects. That means:

• SSE-class transport of binary128 scalars and HFA-like aggregates, following the System V psABI's __float128/Android rules. Oracle against Clang before writing any classification.
• The same compiler-runtime lowering aarch64: lower binary128 long double through the compiler runtime #1720 uses for arithmetic, comparisons, truth and conversions; that frontend code is target-neutral apart from c_ir_target_supports_f128_transport.
• Static folding of the two-limb image, which aarch64: lower binary128 long double through the compiler runtime #1720 also added.
• Variadic passing and va_arg.

Reproduction details

• Revision c3f93e8 (branch of aarch64: lower binary128 long double through the compiler runtime #1720). Base main 76a7bdd behaves the same, since aarch64: lower binary128 long double through the compiler runtime #1720's gate is AAPCS64-only.
• Linux x86-64 host, Clang 18.1.3 for the reference.

Uncertainty

• Unverified: whether Android x86-64 ever passes binary128 in memory in some position (varargs, aggregates past two eightbytes). This needs a Clang ABI oracle before any classifier change.
• Linking needs libgcc/compiler-rt, which buster's native link does not provide (driver/link: _Float16 conversions emit calls to libgcc helpers (__truncdfhf2, __extendhfsf2) that Buster's native link never provides #1272).

Done when

The four snippets above compile for x86_64-linux-android in all MIR allocators with zero fallback, a Clang-oracled fixture (like compiler_driver_test_aarch64_binary128_runtime) passes, and the stale c_ir_target_supports_f80 comment is corrected.