[PATCH] D71600: PowerPC 32-bit - forces 8 byte lock/lock_free decisions at compiled time

[Alfredo Dal'Ava Júnior via Phabricator via cfe-commits]

adalava added a comment.

In D71600#1867135 <https://reviews.llvm.org/D71600#1867135>, @efriedma wrote:

> For the clang change, we should do something like D72579 <https://reviews.llvm.org/D72579>, not explicitly check for a specific target in target-independent code.


right, I'll retest everything using D72579 <https://reviews.llvm.org/D72579>.

> For compiler-rt, are you really disabling COMPILER_RT_EXCLUDE_ATOMIC_BUILTIN?  Are you sure you understand the implications of that?

I didn't  understood "disable COMPILER_RT_EXCLUDE_ATOMIC_BUILTIN", it's not intentional. 
If it's the change around atomic.c:131, what I expect is make IS_LOCK_FREE_8 return false. I don't want it to make to __c11_atomic_is_lock_free(8) as it generates code that should be linked with a libatomic at run time.

> I'm also curious: what part of clang is calling __atomic_is_lock_free?  I can't find any code in LLVM that calls it.

hm, I'm afraid I was not clear in this. When generating FreeBSD images, the libc cross-compiled by unpatched clang gets an entry to external call to __c11_atomic_is_lock_free(). Then, in the resulting system (new sysroot) I get this problem (libatomic dependency) when trying to build clang itself.
While testing with D72579 <https://reviews.llvm.org/D72579> I'll try reproduce it again and will post more info here since I don't have the build logs anymore (I investigated it ~6 months ago).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71600/new/

https://reviews.llvm.org/D71600