Regression in clang-9 for external declare target variable

Hi all,

we think, we found a regression in clang/9:

#pragma omp declare target
int counter = 0;
#pragma omp end declare target

int main(){
     #pragma omp target
  counter++;
     return 0;
}

The code compiles with clang/7 and clang/8, but fails with clang/9:

clang -fopenmp -fopenmp-targets=x86_64 declare-var.c
/usr/bin/ld: /tmp/declare-var-28ddc5.o: relocation R_X86_64_PC32 against symbol `counter' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/usr/bin/ld: cannot find /tmp/declare-var-e0fa25.out

Is this intended behavior?
The error goes away, when making counter static.

Best
Joachim

I don't thinks so. I was aware of some linking problems but this seems
new.

I tested with trunk and with release/9.x.
The code compiles with trunk, with release/9.x I get the same error as with the clang/9 built from the release tarball.

I'm currently running bisect to identify the commit with the fix.

Hans: I assume it's too late to include the bugfix to the clang 9.0.1 release?

Best
Joachim

I assume it is bbc328c62430dd3e2e72973ca85c5c6fb550b227

This is what bisect also showed.

I tried to cherry-pick the commit into release-9.x
I accepted the changes of the commit for merging the declare_target_codegen.cpp test. This solves the issue also in this branch.
But clang/test/OpenMP/declare_target_codegen.cpp fails with:

llvm-project/clang/test/OpenMP/declare_target_codegen.cpp:23:15: error: CHECK-DAG: expected string not found in input
// CHECK-DAG: @hhh_decl_tgt_ref_ptr = weak global i32* null
               ^
<stdin>:11:14: note: scanning from here
%struct.Bake = type { i32 (...)** }
              ^
<stdin>:55:1: note: possible intended match here
@hhh_decl_tgt_ref_ptr = common global i32* null
^

- Joachim

I tested with trunk and with release/9.x.
The code compiles with trunk, with release/9.x I get the same error as
with the clang/9 built from the release tarball.

I'm currently running bisect to identify the commit with the fix.

Hans: I assume it's too late to include the bugfix to the clang 9.0.1
release?

Yes, I think 9.0.1 was essentially done when this was written, and has
since shipped.