[libc][docs] add note on gcc overlay release build

[michaelrj-google]

There's an issue when building with gcc in overlay mode and release mode
that causes build errors. This patch adds a note to the compiler support
site about this.

[llvmbot]

@llvm/pr-subscribers-libc

Author: Michael Jones (michaelrj-google)

Changes

There's an issue when building with gcc in overlay mode and release mode
that causes build errors. This patch adds a note to the compiler support
site about this.

---

Full diff: https://github.com/llvm/llvm-project/pull/89314.diff

1 Files Affected:

• (modified) libc/docs/compiler_support.rst (+4)

diff --git a/libc/docs/compiler_support.rst b/libc/docs/compiler_support.rst
index 00234c22dc2e6f..3e2ab3056273da 100644
--- a/libc/docs/compiler_support.rst
+++ b/libc/docs/compiler_support.rst
@@ -17,6 +17,10 @@ For platforms where only ``GCC`` is natively available but maximum performance
 is required it is possible to bootstrap ``Clang`` with ``GCC`` and then use
 ``Clang`` to build the '`libc``" project.
 
+IMPORTANT NOTE: There is currently an issue when doing an overlay build in
+release mode with GCC. If you want to build with GCC, please either build in
+debug mode or use fullbuild mode. Otherwise, please use clang.
+
 Minimum supported versions
 ==========================
 

[nickdesaulniers]

link to #60481 in the commit description?

I think we should just fix that rather than document the breakage though.

[nickdesaulniers]

diff --git a/libc/src/__support/common.h b/libc/src/__support/common.h
index 53951dc131c2..69268567bb2e 100644
--- a/libc/src/__support/common.h
+++ b/libc/src/__support/common.h
@@ -25,7 +25,7 @@
 #define LLVM_LIBC_FUNCTION_IMPL(type, name, arglist)                           \
   LLVM_LIBC_FUNCTION_ATTR decltype(LIBC_NAMESPACE::name)                       \
       __##name##_impl__ __asm__(#name);                                        \
-  decltype(LIBC_NAMESPACE::name) name [[gnu::alias(#name)]];                   \
+  decltype(LIBC_NAMESPACE::name) name asm(#name);                              \
   type __##name##_impl__ arglist
 #else
 #define LLVM_LIBC_FUNCTION_IMPL(type, name, arglist) type name arglist

tested w/ clang+fullbuild, but I would bet that fixes gcc+overlay

[michaelrj-google]

Does marking the function as asm have any other implications? That seems like it'd be significantly different from aliasing the function.

[nickdesaulniers]

AFAIK they are the same; GCC just doesn't parse the asm string to verify that the alias is defined within the same TU as it does for the alias attribute.

FWIW, we literally do the same thing a line above the one I modified. It looks silly to me why we create 2 aliases 2 different ways to the same identifier. Perhaps there was a reason, but I wasn't able to dig up anything via git archeology. Looks like a mistake to me honestly.

[michaelrj-google]

ah, I looked into it and this annotation sets the assembler name for the function, which appears to also make it available to call in C by that name. Based on that, I think following your suggestion makes sense. I'll create a new PR to apply that.

(doc on how the asm annotation works:
https://gcc.gnu.org/onlinedocs/gcc/extensions-to-the-c-language-family/how-to-use-inline-assembly-language-in-c-code.html#assembler-names-for-functions )

[nickdesaulniers]

superseded by: #89333