This patch fixes the flang detection in the openmp fortran offloading test.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This change works for me, so the test is run and fails with:
ld.lld: error: undefined symbol: increment_at >>>> referenced by /tmp/lit-tmp-hsj2_6gq/basic_array.c.tmp.amdgcn-amd-amdhsa.gfx90a-465f86.o:(__omp_offloading_802_ae2379e_increment_array_l17) >>>> referenced by /tmp/lit-tmp-hsj2_6gq/basic_array.c.tmp.amdgcn-amd-amdhsa.gfx90a-465f86.o:(__omp_offloading_802_ae2379e_increment_array_l17) clang: error: ld.lld command failed with exit code 1 (use -v to see invocation) /home/jsjodin/git/trunk/llvm-project/build/./bin/clang-linker-wrapper: error: 'clang' failed clang: error: linker command failed with exit code 1 (use -v to see invocation) error: command failed with exit status: 1
Yeah, that test fails at the moment. Right now it seems that increment_at isn't registered as a symbol in the LLVM bitcode for the embedded object. I can confirm that this used to work, but I'm still trying to figure out why it doesn't anymore.
Fixes the actual test. Adding !$omp declare target to the offloaded function prevents the OMPFunctionFiltering pass from optimizing it out. I'm not sure if we want public functions to be hidden from object files targeting GPUs, but I think that might be outside the scope of this patch.
LGTM, the test passes for me.
I'm not sure what the correct behavior is. The standard says:
"If a procedure is explicitly or implicitly referenced in a target construct that does not specify a device clause in which the ancestor device-modifier appears then that procedure is treated as if its name had appeared in an enter clause on a declare target directive"
It doesn't say it has to be in the same compilation unit, but it also doesn't seem unreasonable to have to specify declare target if it is outside the compilation unit. @jdoerfert, do you know correct behavior is?