Expected behavior?

 real(4) :: x0,y0
  real(8) :: x1,y1
  real(16) :: x2,y2,z2

  x0=1.0d0 ;x1=1.0d0
  y0=3.0d0 ; y1=3.0d0
  x2=1.0d0
  y2=3.0d0
  z2=x2/y2.   ! this line creates undefined linker symbols
  print*, x0/y0
  print*, x1/y1
!  print*, x2/y2
end program

On an Apple Silicon based Mac installed via home-brew:

Undefined symbols for architecture arm64:
  "___divtf3", referenced from:
      __QQmain in b-984e98.o
ld: symbol(s) not found for architecture arm64
flang-new: error: linker command failed with exit code 1 (use -v to see invocation)

———————————

Hi Khb, thanks for your interest in flang.

Those missing symbols are provided by compiler-rt (sometimes called clang-rt), which the compiler should have added the link options for automatically. I suspect your installation of flang is missing compiler-rt or compiler-rt could not be found in the location where it is expected to be. Do you have a working clang installation built from the same version of llvm as your flang? If so, there should be a copy of compiler-rt there which you could link manually. It will be called something like libclang_rt. The compiler expects to find compiler-rt in the resource dir. On my aarch64 linux system that looks like

$INSTALL_DIR/lib/clang/$LLVM_VERSION/lib/aarch64-unknown-linux-gnu/libclang_rt.builtins.a.

Please let me know if that worked.

As this flang was installed by homebrew, it isn’t instantly obvious … but I suspect that they either didn’t install it (it’s not where I would have thought it would be). Aside from the system/xcode installed clang, there are llvm16 and llvm19 instances installed (presumably different “brew formula” included them for various packages). For example:


/opt/homebrew/Cellar/llvm/19.1.7_1/lib/clang/19/lib/darwin>ls
libclang_rt.asan_abi_osx.a                  libclang_rt.stats_osx_dynamic.dylib
libclang_rt.asan_osx_dynamic.dylib          libclang_rt.tsan_osx_dynamic.dylib
libclang_rt.cc_kext.a                       libclang_rt.ubsan_minimal_osx_dynamic.dylib
libclang_rt.fuzzer_interceptors_osx.a       libclang_rt.ubsan_minimal_osx.a
libclang_rt.fuzzer_no_main_osx.a            libclang_rt.ubsan_osx_dynamic.dylib
libclang_rt.fuzzer_osx.a                    libclang_rt.xray_osx.a
libclang_rt.lsan_osx_dynamic.dylib          libclang_rt.xray-basic_osx.a
libclang_rt.osx.a                           libclang_rt.xray-fdr_osx.a
libclang_rt.profile_osx.a                   libclang_rt.xray-profiling_osx.a
libclang_rt.rtsan_osx_dynamic.dylib         liborc_rt_osx.a
libclang_rt.stats_client_osx.a

No .builtins.a

thanks for the quick diagnosis!

Thanks for the information. I have found a mac and was able to reproduce the issue. I will report the issue to homebrew.

It seems none of those libclang_rt.* libararies contain the symbol we need so there’s not much you can do without a fix from homebrew.

You can work around this by building with optimization. E.g. flang-new -O1 file.f90. In that case the call to that math function is never generated. If using optimization isn’t acceptable for your use case you could build compiler-rt yourself (the 19.1.7 tag should be compatible, you don’t need to rebuild flang, which is inconvenient on most Macs because it needs a lot of memory).

Update:

divtf3 is deliberately excluded from compiler-rt on mac. See llvm-project/compiler-rt/lib/builtins/Darwin-excludes at main · llvm/llvm-project · GitHub.

It does not appear to be built into the osx system libraries either (at least I couldn’t find the right think to link to using MacOS’s built in clang).

So I suspect it is wrong to generate calls to this function at any optimization level for macos. I notice that clang doesn’t support __float128 at all on MacOS.

Unfortunately I don’t think we can support real(16) on MacOS until compiler-rt and clang also support it.

Since Flang 19 (which the homebrew package is based on) diagnostics for real(16) have been improved e.g. [flang] Warn when F128 is unsupported (#102147) by tblah · Pull Request #106957 · llvm/llvm-project · GitHub

This should be available on homebrew when LLVM 20 is released soon.

Thank you for running this to ground.