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)
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
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:
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).
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.