Open mathomp4 opened 2 days ago
Note: C doesn't seem to be affected:
> clang -fopenmp test.c
> OMP_NUM_THREADS=2 ./a.out
Hello, world.
Hello, world.
I think you're a victim of this: https://github.com/llvm/llvm-project/pull/112202.
We need libatomic for some atomic operations. With the PR, Flang now recognizes this and automatically adds -latomic to the link line, when OpenMP is active and if it was configured to use the GCC runtime. If you setup Flang to work with the Clang C runtime, then the atomic operations should be included there and libatomic should not be needed.
Flang uses -latomic and then relies on the default search path in the environment for libraries.
BTW, before the PR, you would have seen a linker error barfing at missing symbols, when you have used certain atomic operations, e.g. CAS atomics.
PS: Please try setting LIBRARY_PATH
to the location of libatomic
. That should resolve the issue.
If not, please post the full output of flang -v -fopenmp ...
.
PS: Please try setting
LIBRARY_PATH
to the location oflibatomic
. That should resolve the issue.
Sadly, doesn't seem to help:
> echo $LIBRARY_PATH
/ford1/share/gmao_SIteam/llvm-flang/2024-10-22/lib:/ford1/local/gcc/gcc-12.1.0/lib64
> flang-new -fopenmp test.F90
flang-20: warning: OpenMP support in flang is still experimental [-Wexperimental-option]
/usr/bin/ld: cannot find /usr/lib64/libatomic.so.1.2.0
flang-20: error: linker command failed with exit code 1 (use -v to see invocation)
If not, please post the full output of
flang -v -fopenmp ...
.
> flang -v -fopenmp test.F90
flang version 20.0.0git (git@github.com:GEOS-ESM/build-llvm-flang.git 697744d14fec6505d07f95249388ac2452ee5151)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /ford1/share/gmao_SIteam/llvm-flang/2024-10-22/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-redhat-linux/8
Selected GCC installation: /usr/lib/gcc/x86_64-redhat-linux/8
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
flang-20: warning: OpenMP support in flang is still experimental [-Wexperimental-option]
"/ford1/share/gmao_SIteam/llvm-flang/2024-10-22/bin/flang" -fc1 -triple x86_64-unknown-linux-gnu -emit-obj -fcolor-diagnostics -mrelocation-model pic -pic-level 2 -pic-is-pie -target-cpu x86-64 -fopenmp -resource-dir /ford1/share/gmao_SIteam/llvm-flang/2024-10-22/lib/clang/20 -mframe-pointer=all -o /home/mathomp4/tmpdir/test-68da60.o -x f95-cpp-input test.F90
"/usr/bin/ld" --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -pie -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/Scrt1.o /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/8/crtbeginS.o -L/ford1/share/gmao_SIteam/llvm-flang/2024-10-22/bin/../lib/x86_64-unknown-linux-gnu -L/usr/lib/gcc/x86_64-redhat-linux/8 -L/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/lib -L/usr/lib -L/ford1/share/gmao_SIteam/llvm-flang/2024-10-22/lib -L/ford1/local/gcc/gcc-12.1.0/lib64 /home/mathomp4/tmpdir/test-68da60.o -L/ford1/share/gmao_SIteam/llvm-flang/2024-10-22/lib -lFortranFloat128Math --as-needed -lquadmath --no-as-needed -lFortranRuntime -lFortranDecimal -latomic -lm -lomp -L/ford1/share/gmao_SIteam/llvm-flang/2024-10-22/lib -lgcc --as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/8/crtendS.o /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crtn.o
/usr/bin/ld: cannot find /usr/lib64/libatomic.so.1.2.0
flang-20: error: linker command failed with exit code 1 (use -v to see invocation)
This is interesting. I mean, I see in there:
-L/ford1/local/gcc/gcc-12.1.0/lib64 ... -latomic
It just seems hellbent on finding it in /usr/lib64
. Here is the modulefile I'm using in case anything pops out. It's pretty boring.
Also, learned that apparently there is a flang
alias. Huh.
Also, learned that apparently there is a
flang
alias. Huh.
Just quickly between meetings: It's the other way round. It's flang
now and flang-new
is the alias. We have switched about two weeks ago, so that some point flang-new
will cease to exist.
I'll have a look at the other things when I have a free minute today. Thanks for sharing the output!
Also, learned that apparently there is a
flang
alias. Huh.Just quickly between meetings: It's the other way round. It's
flang
now andflang-new
is the alias. We have switched about two weeks ago, so that some pointflang-new
will cease to exist.
Well then. Time to scour my system for things (Makefiles, etc.) that have been looking for flang-new
!
And thanks for looking. For now I can sort of "shove" CMake to be happy with:
-DCMAKE_EXE_LINKER_FLAGS='-L/ford1/local/gcc/gcc-12.1.0/lib64 -latomic'
Not portable, but I can keep going for now.
All,
Last month, I built
flang-new
and I was able to build OpenMP code:However, I built
flang-new
as of yesterday and:Now, I do have
libatomic.so.1.2.0
and it was around when I builtflang-new
with GCC 12.1.0 but it's the GCC 12 one:and I have that in my
LD_LIBRARY_PATH
:but it is not in
/usr/lib64
:So if I build pointing to that:
My question is: why does
flang-new
seem to thinklibatomic
is in/usr/lib64
? The build couldn't have seen it there since it didn't exist there during the build. And it's not likeldd
wants it there: