-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[libc] Disable hidden visibility for LIBC_NAMESPACE with GCC #98549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
GCC emits a warning when using the visibility attribute which needs to be diagnosed and addressed, but this change should unbreak the GCC build as a temporary workaround.
@llvm/pr-subscribers-libc Author: Petr Hosek (petrhosek) ChangesGCC emits a warning when using the visibility attribute which needs to be diagnosed and addressed, but this change should unbreak the GCC build as a temporary workaround. Full diff: https://github.com/llvm/llvm-project/pull/98549.diff 1 Files Affected:
diff --git a/libc/src/__support/macros/config.h b/libc/src/__support/macros/config.h
index 5c3ec634449f8..23436365cc544 100644
--- a/libc/src/__support/macros/config.h
+++ b/libc/src/__support/macros/config.h
@@ -28,6 +28,7 @@
#define LIBC_HAS_FEATURE(f) 0
#endif
+#ifndef __GNUC__
// Declare a LIBC_NAMESPACE with hidden visibility. `namespace
// LIBC_NAMESPACE_DECL {` should be used around all declarations and definitions
// for libc internals as opposed to just `namespace LIBC_NAMESPACE {`. This
@@ -37,5 +38,10 @@
// dynamic relocations. This does not affect the public C symbols which are
// controlled independently via `LLVM_LIBC_FUNCTION_ATTR`.
#define LIBC_NAMESPACE_DECL [[gnu::visibility("hidden")]] LIBC_NAMESPACE
+#else
+// TODO(#98548): GCC emits a warning when using the visibility attribute which
+// needs to be diagnosed and addressed.
+#define LIBC_NAMESPACE_DECL LIBC_NAMESPACE
+#endif
#endif // LLVM_LIBC_SRC___SUPPORT_MACROS_CONFIG_H
|
libc/src/__support/macros/config.h
Outdated
@@ -28,6 +28,7 @@ | |||
#define LIBC_HAS_FEATURE(f) 0 | |||
#endif | |||
|
|||
#ifndef __GNUC__ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think clang also define this macro. Probably #ifdef __clang__
is safer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
libc/src/__support/macros/config.h
Outdated
@@ -28,6 +28,7 @@ | |||
#define LIBC_HAS_FEATURE(f) 0 | |||
#endif | |||
|
|||
#ifndef __GNUC__ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
__GNUC__
is defined by many compilers, including Clang.
You need #ifdef __clang__
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
libc/src/__support/macros/config.h
Outdated
@@ -28,6 +28,7 @@ | |||
#define LIBC_HAS_FEATURE(f) 0 | |||
#endif | |||
|
|||
#ifndef __GNUC__ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't clang define __GNUC__
for compatibility? Would it be better to instead use #ifdef __clang__
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
What is the warning? This should work in C++17 as far as I know https://godbolt.org/z/j94hxsTGa. |
From the buildbot:
|
) GCC emits a warning when using the visibility attribute which needs to be diagnosed and addressed, but this change should unbreak the GCC build as a temporary workaround. The issue is tracked as llvm#98548.
GCC emits a warning when using the visibility attribute which needs to be diagnosed and addressed, but this change should unbreak the GCC build as a temporary workaround.
The issue is tracked as #98548.