-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix clang16 and clang17 builds #905
Conversation
…pp.exe by adding -no-pie madgraph5#904
…ng OMP only for clang16 madgraph5#904
…6 builds madgraph5#904 (disabling OMP only for clang16; add -no-pie for fcheck_cpp.exe)
This closes #904 |
…ster for easier merging git checkout upstream/master $(git ls-tree --name-only HEAD */CODEGEN*txt)
…ng OMP only for clang17 madgraph5#904
…7 builds madgraph5#904 (disable OMP also for clang17)
In the meantime I also included similar fixes, and some wrappers, for clang16 |
…ster for easier merging git checkout upstream/master $(git ls-tree --name-only HEAD */CODEGEN*txt)
…ph5#904: remove link-time -no-pie, add compiler-time -fPIC to fortran
…5#904: remove link-time -no-pie, add compiler-time -fPIC to fortran
…adgraph5#904, adding -fPIC to fortran compilation
…ODEGEN logs from the latest upstream/master for easier merging git checkout upstream/master $(git ls-tree --name-only HEAD */CODEGEN*txt)
And I improved the fix, adding -fPIC to fortran compilation instead of -no-pie to clang linking. One word of motivation:
|
…h.h madgraph5#905 and test_misc.cc/valgrind.h madgraph5#906 Add valgrind.h for all processes for d in $(git ls-tree --name-only HEAD */SubProcesses); do git add $d/valgrind.h $d/*/valgrind.h; done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Andrea, Back on this one, given that #900 is merged and that our default is no openmp, would it not make more sense to simply let the code to crash (or refuse to compile) if the user ask for openmp with such compiler? I guess that you face issue when compiling with such compiler or was it just to simplify some test? Cheers, Olivier |
Hi @oliviermattelaer thanks! True OpenMP is now disabled by default, but one can always reenable it. Here what I wanted to makerk is that we know that we have not ported the openmp stuff to clang, we (well I) did not find a way to make it work. If you prefer I can replace the
by something like
Would that be better? This was impossible when OpenMP was the default, but now that it is disabled by default, this can be a way to signal that it is not supported. In any case I would definitely do something to signal that this was tested and found problematic. There's so many use cases and combinations, that I think it is important to makrk in the code what we are able to do and what we are not able to do. |
Yes, I like it :-) Thanks, Olivier |
…h5#900 and submod madgraph5#897) into clang
…r if OpenMP builds are attempted on clang16/17 (as discussed with Olivier in madgraph5#905)
…s from the latest upstream/master for easier merging git checkout upstream/master $(git ls-tree --name-only HEAD */CODEGEN*txt)
Thanks Olivier :-) Ok I have made the change and regenerated code. When the CI completes I will merge. |
The CI is showing Merging now. |
…aster with OMP madgraph5#900 and submod madgraph5#897) into gtest Fix conflicts in epochX/cudacpp/gg_tt.mad/CODEGEN_mad_gg_tt_log.txt git checkout clang gg_tt.mad/CODEGEN_mad_gg_tt_log.txt Note: MG5AMC has been updated including mg5amcnlo#107
…aster with clang madgraph5#905, OMP madgraph5#900 and submod madgraph5#897) into gtest Fix conflicts in epochX/cudacpp/gg_tt.mad/CODEGEN_mad_gg_tt_log.txt git checkout clang gg_tt.mad/CODEGEN_mad_gg_tt_log.txt Note: MG5AMC has been updated including mg5amcnlo#107
…ng PR madgraph5#905, constexpr_math.h PR madgraph5#908 and runTest/cudaDeviceReset PR madgraph5#909 Add valgrind.h and its symlink in the repo for gg_tt.mad The new runTest.cc template now has a (commented out) proof of concept for including two tests (with/without multichannel) madgraph5#896, I will resume from there After building bldall, the following succeeds for bck in none sse4 avx2 512y 512z cuda; do echo $bck; ./build.${bck}_d_inl0_hrd0/runTest_*.exe; done This instead is crashing (again?) for some AVX values for bck in none sse4 avx2 512y 512z cuda; do echo $bck; valgrind ./build.${bck}_d_inl0_hrd0/runTest_*.exe; done On closer inspection, this is because valgrind does not support AVX512, so this is ok
Hi @oliviermattelaer these are small fixes for clang16 builds, can you have a look please? Thanks Andrea