[flang] cpp-type.h: add HAS_QUADMATHLIB to REAL(16) / CppFloat128Type guards

Subprojects Flang
1

Hi,

I have a small change to flang/include/flang/Runtime/cpp-type.h that I’d like to upstream and wanted to check if this looks reasonable to the community before filing a review.

Background: HAS_QUADMATHLIB is already used in flang/lib/Evaluate/host.h and flang/lib/Evaluate/intrinsics-library.cpp to enable quadmath-backed constant folding. However, cpp-type.h — which maps Fortran types to C++ types for the runtime — only checks HAS_FLOAT128 and HAS_LDBL128 when deciding whether __float128 / REAL(16) is available, and misses HAS_QUADMATHLIB.

Since HAS_QUADMATHLIB implies __float128 is accessible (quadmath requires it), the fix is to add it to both guards:

-#elif HAS_FLOAT128
+#elif HAS_FLOAT128 || HAS_QUADMATHLIB
using CppFloat128Type = __float128;
#endif
-#if __STDCPP_FLOAT128_t || HAS_LDBL128 || HAS_FLOAT128
+#if __STDCPP_FLOAT128_t || HAS_LDBL128 || HAS_FLOAT128 || HAS_QUADMATHLIB
template <> struct CppTypeForHelper<TypeCategory::Real, 16> {
using type = CppFloat128Type;
};

Without this, building with -DFLANG_RUNTIME_F128_MATH_LIB=libquadmath -DFLANG_INCLUDE_QUADMATH_H=ON produces a runtime that has the quadmath math library wired up but no CppTypeFor<Real, 16> — the type mapping that the rest of the runtime relies on for REAL(16) operations.

Does this look like an appropriate fix? Happy to open a Phabricator/GitHub review if so.

Note on affected platforms: On x86-64 (GCC ≥ 7 / Clang ≥ 7) and PPC (GCC ≥ 8), HAS_FLOAT128 is already set unconditionally, so the missing HAS_QUADMATHLIB is harmless there. The gap is visible on other architectures — we encountered it on RISC-V — where HAS_FLOAT128 is never defined but __float128 becomes available via quadmath.

2

At first glance - why not just update float128.h?

3

Possibly related change that could use some eyes on it: [flang] Fix POSIX.1/XPG checks in intrinsics-library.cpp by rorth · Pull Request #201072 · llvm/llvm-project · GitHub

4

float128.h would be the right place if the goal was to signal that float128 arithmetic works.

The point is that HAS_QUADMATHLIB is a CMake-defined macro and isn’t visible in float128.h include chain, so we can’t gate it there.

If that is the case, the better fix would be in float128.h to extend the allow-list to cover RISCV (add definition of HAS_FLOAT128), which would fix all the HAS_LDBL128 || HAS_FLOAT128 guards in one shot — separate from the HAS_QUADMATHLIB question.

But are we sure that RISCV should be added to the allow-list in float128.h? Does it support float128 arithmetic at all? If not, then we shouldn’t add it to the allow-list, and instead we should just define HAS_QUADMATHLIB for RISCV in CMakeLists.txt, which would fix the issue without changing float128.h.