[flang-commits] [flang] [draft][flang] Query backend support for quad-precision compilation decision (PR #182230)

[Shunsuke Watanabe via flang-commits]

s-watanabe314 wrote:

> when flang is being used to compile some code, then wouldn't flang itself always have to be built with everything needed to support kind=16? So ieee_arithmetic.mod would always have to be built with support for kind=16? Is my understanding of this correct?

Ideally, I agree that such a build approach would be correct.  However, with the current flang, if `ieee_arithmetic.mod` always includes `kind=16`,  I believe a similar issue as reported in #158790 would occur in environments that don't support quad-precision.

The reason for the error if `ieee_arithmetic.mod` always includes `kind=16` is as follows:
1. A user attempts to compile a program that includes `use ieee_arithmetic` for an environment where quad-precision is **not** supported.
2. Flang checks the target, determines there's **no** `kind=16` support, and then loads `ieee_arithmetic.mod`.
3. However, since `ieee_arithmetic.mod` contains `real(16)`, a compilation error occurs. As a result, the user cannot compile any code that includes `ieee_arithmetic` anywhere.

To avoid this, I think one of the following implementations, for example, would be necessary:
- During module build-time, flang checks if it supports quad-precision and builds `ieee_arithmetic.mod` accordingly.
- Always include kind=16 in ieee_arithmetic.mod, but somehow avoid that line at use-time.
- Always build both `ieee_arithmetic.mod` (without `kind=16`) and a module like `ieee_arithmetic_R16.mod` (with `kind=16`), and select which file to load at use-time based on the target.

I am still investigating the feasibility of each of these methods. There might be even better approaches.

https://github.com/llvm/llvm-project/pull/182230