[Flang] `.mod` files built into `include/flang/` do not support multiple target architectures

[s-watanabe314]

When Flang is built with multiple target architectures specified for -DLLVM_TARGETS_TO_BUILD, .mod files are created only for the default target architecture and not for other architectures.

This becomes a problem, for example, when building on an X86_64 machine targeting both X86_64 and AArch64.

• CMake configuration:

cmake \
  -G Ninja \
  -DCMAKE_INSTALL_PREFIX=/<install_dir> \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_PROJECTS="clang;mlir;flang" \
  -DLLVM_TARGETS_TO_BUILD="AArch64;X86" \
  -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu" \
  /<llvm_dir>/llvm-project/llvm

In this case, .mod files are likely built by this command, but since no target architecture is specified, they seem to be built only for the default X86_64. This leads to cross-compilation failures like the following:

• foo.f90:

program main
  use, intrinsic :: IEEE_ARITHMETIC
  implicit none
end program

• Compilation error:

$ flang --target=aarch64-unknown-linux-gnu --sysroot=<GCC_TOOLCHAIN_DIR>/libc --gcc-toolchain=<GCC_TOOLCHAIN_DIR> foo.f90 -c -o x86_to_aarch.o

error: Semantic errors in foo.f90
/<install_dir>/bin/../include/flang/ieee_arithmetic.mod:143:1: error: REAL(KIND=10) is not an enabled type for this target
  real(10),intent(in)::x
  ^^^^^^^^^^^^^^^^^^^^^^
/<install_dir>/bin/../include/flang/ieee_arithmetic.mod:183:1: error: REAL(KIND=10) is not an enabled type for this target
  real(10),intent(in)::y
  ^^^^^^^^^^^^^^^^^^^^^^
/<install_dir>/bin/../include/flang/ieee_arithmetic.mod:223:1: error: REAL(KIND=10) is not an enabled type for this target
  real(10),intent(in)::y
  ^^^^^^^^^^^^^^^^^^^^^^
...

This error seems to occur because ieee_arithmetic.mod is built for X86_64 with REAL(KIND=10) included, and then compiled for AArch64. A similar issue was also reported in #146876.

Other modules also contain values that differ from the target architecture because they are built for X86_64. We have confirmed the following:

• iso_c_binding.mod
  • Built natively for AArch64
    • integer(4),parameter::c_long_double=16_4
  • Built on X86_64 with -DLLVM_TARGETS_TO_BUILD="AArch64;X86"
    • integer(4),parameter::c_long_double=10_4
• iso_fortran_env_impl.mod
  • Built natively for AArch64
    • integer(4),parameter::__builtin_real_kinds(1_8:*)=[INTEGER(4)::2_4,3_4,4_4,8_4,16_4]
  • Built on X86_64 with -DLLVM_TARGETS_TO_BUILD="AArch64;X86"
    • integer(4),parameter::__builtin_real_kinds(1_8:*)=[INTEGER(4)::2_4,3_4,4_4,8_4,10_4]

To resolve this, it might be necessary to change the build process to create all .mod files for each target architecture and then select the appropriate .mod file during compilation.

[llvmbot]

@llvm/issue-subscribers-flang-build

Author: Shunsuke Watanabe (s-watanabe314)

When Flang is built with multiple target architectures specified for `-DLLVM_TARGETS_TO_BUILD`, `.mod` files are created only for the default target architecture and not for other architectures.

This becomes a problem, for example, when building on an X86_64 machine targeting both X86_64 and AArch64.

• CMake configuration:

cmake \
  -G Ninja \
  -DCMAKE_INSTALL_PREFIX=/<install_dir> \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_PROJECTS="clang;mlir;flang" \
  -DLLVM_TARGETS_TO_BUILD="AArch64;X86" \
  -DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu" \
  /<llvm_dir>/llvm-project/llvm

In this case, .mod files are likely built by this command, but since no target architecture is specified, they seem to be built only for the default X86_64. This leads to cross-compilation failures like the following:

• foo.f90:

program main
  use, intrinsic :: IEEE_ARITHMETIC
  implicit none
end program

• Compilation error:

$ flang --target=aarch64-unknown-linux-gnu --sysroot=<GCC_TOOLCHAIN_DIR>/libc --gcc-toolchain=<GCC_TOOLCHAIN_DIR> foo.f90 -c -o x86_to_aarch.o

error: Semantic errors in foo.f90
/<install_dir>/bin/../include/flang/ieee_arithmetic.mod:143:1: error: REAL(KIND=10) is not an enabled type for this target
  real(10),intent(in)::x
  ^^^^^^^^^^^^^^^^^^^^^^
/<install_dir>/bin/../include/flang/ieee_arithmetic.mod:183:1: error: REAL(KIND=10) is not an enabled type for this target
  real(10),intent(in)::y
  ^^^^^^^^^^^^^^^^^^^^^^
/<install_dir>/bin/../include/flang/ieee_arithmetic.mod:223:1: error: REAL(KIND=10) is not an enabled type for this target
  real(10),intent(in)::y
  ^^^^^^^^^^^^^^^^^^^^^^
...

This error seems to occur because ieee_arithmetic.mod is built for X86_64 with REAL(KIND=10) included, and then compiled for AArch64. A similar issue was also reported in #146876.

Other modules also contain values that differ from the target architecture because they are built for X86_64. We have confirmed the following:

• iso_c_binding.mod
  • Built natively for AArch64
    • integer(4),parameter::c_long_double=16_4
  • Built on X86_64 with -DLLVM_TARGETS_TO_BUILD="AArch64;X86"
    • integer(4),parameter::c_long_double=10_4
• iso_fortran_env_impl.mod
  • Built natively for AArch64
    • integer(4),parameter::__builtin_real_kinds(1_8:*)=[INTEGER(4)::2_4,3_4,4_4,8_4,16_4]
  • Built on X86_64 with -DLLVM_TARGETS_TO_BUILD="AArch64;X86"
    • integer(4),parameter::__builtin_real_kinds(1_8:*)=[INTEGER(4)::2_4,3_4,4_4,8_4,10_4]

To resolve this, it might be necessary to change the build process to create all .mod files for each target architecture and then select the appropriate .mod file during compilation.

[jfuchs-kmt]

@s-watanabe314 Sorry for the bump, do you know of any workaround for this issue currently? Generally this and the related issue #146876 generally block us from using any library containing REAL(10) (and I guess REAL(16)) when compiling with -fopenmp-targets=<...>. Any idea or fix would help us tremendously!

[s-watanabe314]

I apologize, but I haven't found a solution to this issue yet. However, replacing the module files included in the cross-compiler with ones built on the same environment as the target might work.

For example, in the case of this issue, replacing the ieee_arithmetic.mod of an X86_64 cross-compiler with one built as a native compiler on AArch64 should resolve the KIND=10 problem. However, this method would then include KIND=16 in ieee_arithmetic.mod, leading to the issue #160060. Replacing it with one built in an environment that includes neither KIND=10 nor KIND=16 might work, but I haven't tried it. Even if this approach is successful, it would only enable compilation for a specific target, and it's unclear if it would allow compilation for various targets. I hope this idea is helpful.

[luporl]

It looks like #137828 is addressing a similar issue. Maybe it will also fix this one.