[builtins] Something wrong with librt_has_divtc3 feature on older clang

[aemerson]

The bot https://green.lab.llvm.org/green/job/clang-stage1-RA/ was failing after d2ce3e9 went in. Something about feature detection being broken for clang, I don't really have the time to investigate.

Workaround by guarding the failing test here: #71876

[rorth]

Unfortunately, this Issue massively lacks detail:

• It was hard to determine the native target: x86_64-apple-darwin20.6.0 (it's buried deeply in the logs)
• The exact failure mode is missing, too: instead of linking to the bot as a whole, it should link to (or better cite) the concrete failure message

[rorth]

Since @aemerson provided no information on the Darwin 20 failure whatsoever, I did some digging myself. What I found was in incredible mess, this failure being just the tip of the iceberg. @arichardson The rework of the builtins code has a large number of issues:

In a x86_64-apple-darwin20.6.0 VM with Apple clang version 13.0.0 (clang-1300.0.29.30) and 77d75dc reverted, I found the actual failure that I couldn't seen anywhere in the buildbot's logs:

/System/Volumes/Data/vol/llvm/src/llvm-project/local/compiler-rt/test/builtins/Unit/divtc3_test.c:18:17: error: unknown type name 'Qcomplex'
   18 | COMPILER_RT_ABI Qcomplex __divtc3(tf_float __a, tf_float __b, tf_float __c,
      |                 ^
/System/Volumes/Data/vol/llvm/src/llvm-project/local/compiler-rt/test/builtins/Unit/divtc3_test.c:18:35: error: unknown type name 'tf_float'; did you mean 'xf_float'?
   18 | COMPILER_RT_ABI Qcomplex __divtc3(tf_float __a, tf_float __b, tf_float __c,
      |                                   ^~~~~~~~
      |                                   xf_float
[...]

I then looked into the equivalent LLVM 17.x build, the Builtins-x86_64-darwin :: divtc3_test.c test PASSed, while now it's just skipped.

However, in LLVM 17, divtc3.o contains a definition of __divtc3, while on main there's no such definition. This breaks the ABI (if LLVM cares about such trivialities; and not only on Darwin; the same issue exists e.g. on Solaris/sparc).

What's worse, librt_has_divtc3 is always set, even if no such symbol exists in divtc3.c.o (i.e. on both LLVM 17 and main).

Things get even worse because the builtins tests aren't even run in a runtimes build (-DLLVM_ENABLE_RUNTIMES=compiler-rt, which is the default on most buildbots these days). This way, any problems with the builtins are completely missed by default. The Solaris buildbots are different here because the still use a projects build (-DLLVM_ENABLE_PROJECTS=compiler-rt) for various reasons.

Solaris/sparc has all the same issues, but I guess I'll file a new issue for that one because things are even more ugly due to the XPASS reported in Issue #71876.

[arichardson]

Looking at how these features are defined, it appears they are purely set based on whether the source file is part of the compilation, but divtc.c is always added to the sources and the symbol is conditionally compiled:

llvm-project/compiler-rt/test/builtins/CMakeLists.txt

Line 99 in c5a306f

list(APPEND BUILTINS_LIT_SOURCE_FEATURES "librt_has_${FILE_NAME_FILTERED}")

The more reliable approach would be to either look at the resulting symbol table or try to compile something like the following as part of the lit setup:

extern void __divtc(void);
int main() {
   return &__divtc != 0;
}

[aemerson]

Sorry for the issue lacking details. I'm extremely short on time. We really need the bots to stay green so anyone should feel free to revert my change. If you do so however please revert the initial commit from @arichardson. It sounds like the whole thing needs to be rethought.

[rorth]

I've now filed Issue #72511 for the builtins (and other) tests completely missing in runtimes builds.