Skip to content

[clang][Sema] Don't warn for implicit uses of builtins in system headers #138205

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

sarnex
Copy link
Member

@sarnex sarnex commented May 1, 2025

When trying to remove the usage of __has_builtin on MSVC CUDA ARM for some builtins, the recommended direction was to universally declare the MSVC builtins on all platforms and require the header providing declarations to be included. This was done here.

However, some MSVC headers already use the MSVC builtins without including the header, so we introduce a warning for anyone compiling with MSVC for this target, so the above change had to be reverted.

As a workaround, don't warn for implicit uses of library functions if it's inside a system header, unless system header warnings are enabled.

If this PR is accepted I will re-apply the original commit reworking the builtins.

Signed-off-by: Sarnie, Nick <nick.sarnie@intel.com>
@sarnex sarnex marked this pull request as ready for review May 2, 2025 14:24
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels May 2, 2025
@llvmbot
Copy link
Member

llvmbot commented May 2, 2025

@llvm/pr-subscribers-clang

Author: Nick Sarnie (sarnex)

Changes

When trying to remove the usage of __has_builtin on MSVC CUDA ARM for some builtins, the recommended direction was to universally declare the MSVC builtins on all platforms and require the header providing declarations to be included. This was done here.

However, some MSVC headers already use the MSVC builtins without including the header, so we introduce a warning for anyone compiling with MSVC for this target, so the above change had to be reverted.

As a workaround, don't warn for implicit uses of library functions if it's inside a system header, unless system header warnings are enabled.

If this PR is accepted I will re-apply the original commit reworking the builtins.


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

3 Files Affected:

  • (modified) clang/lib/Sema/SemaDecl.cpp (+6-1)
  • (added) clang/test/Sema/Inputs/builtin-system-header.h (+1)
  • (added) clang/test/Sema/builtin-system-header.c (+8)
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index a3285e8f6f5a2..37008f9eb3235 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -2376,9 +2376,14 @@ NamedDecl *Sema::LazilyCreateBuiltin(IdentifierInfo *II, unsigned ID,
     return nullptr;
   }
 
+  // Warn for implicit uses of header dependent libraries,
+  // except in system headers.
   if (!ForRedeclaration &&
       (Context.BuiltinInfo.isPredefinedLibFunction(ID) ||
-       Context.BuiltinInfo.isHeaderDependentFunction(ID))) {
+       Context.BuiltinInfo.isHeaderDependentFunction(ID)) &&
+      (!getDiagnostics().getSuppressSystemWarnings() ||
+       !Context.getSourceManager().isInSystemHeader(
+           Context.getSourceManager().getSpellingLoc(Loc)))) {
     Diag(Loc, LangOpts.C99 ? diag::ext_implicit_lib_function_decl_c99
                            : diag::ext_implicit_lib_function_decl)
         << Context.BuiltinInfo.getName(ID) << R;
diff --git a/clang/test/Sema/Inputs/builtin-system-header.h b/clang/test/Sema/Inputs/builtin-system-header.h
new file mode 100644
index 0000000000000..ebd5655e6f8ef
--- /dev/null
+++ b/clang/test/Sema/Inputs/builtin-system-header.h
@@ -0,0 +1 @@
+#define MACRO(x,y) _InterlockedOr64(x,y);
diff --git a/clang/test/Sema/builtin-system-header.c b/clang/test/Sema/builtin-system-header.c
new file mode 100644
index 0000000000000..83c3c15e314a7
--- /dev/null
+++ b/clang/test/Sema/builtin-system-header.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -fms-extensions -fsyntax-only -verify -triple arm64-windows -isystem %S/Inputs %s
+
+// expected-no-diagnostics
+#include <builtin-system-header.h>
+
+void foo() {
+  MACRO(0,0);
+}

@sarnex sarnex requested review from rnk, Artem-B and mstorsjo May 2, 2025 14:25
@Artem-B
Copy link
Member

Artem-B commented May 2, 2025

Something does not add up here. AFAICT, using builtins w/o explicitly declaring them is something that's done all the time. https://godbolt.org/z/ha47W53dh

In that sense, we should not be needing to filter out the diagnostics coming from the system headers only. There should not be any diagnostics for those builtins at all, from anywhere.

I must be missing something here. @rnk -- is the requirement for builtin declarations a windows-specific quirk?

@sarnex
Copy link
Member Author

sarnex commented May 2, 2025

I think it's because we are explicitly marking these builtins as requiring a header. If they aren't defined that way in the Tablegen file then you won't see this warning and won't need this change.

I made the builtins require a header based on feedback from @rnk in the earlier PR, and his suggestion on my regression fix PR to still require the header but follow what we did for _m_prefetchw, but it seems the same idea was tried there but that was also reverted for what seems to be the same exact problem. See here and revert here.

So if I understand the state of affairs correctly if we want to prevent the winnt.h warning we need to either:

  1. Not require the header so we won't ever warn.
  2. Don't warn in this case, and this PR attempts to implement one idea for that to try to honor rnk's feedback.

Let me know if anyone has suggestions, sorry this change is so drawn out :)

@Artem-B
Copy link
Member

Artem-B commented May 2, 2025

OK. This makes sense.

sorry this change is so drawn out :)

What matters is that you're making progress, and I appreciate your work on getting this issue sorted out the right way.

Comment on lines +2383 to +2386
Context.BuiltinInfo.isHeaderDependentFunction(ID)) &&
(!getDiagnostics().getSuppressSystemWarnings() ||
!Context.getSourceManager().isInSystemHeader(
Context.getSourceManager().getSpellingLoc(Loc)))) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may want to narrow down the scope of which diagnostics we want to suppress and when.
While we do know that we may need it for these builting for windows on ARM, I can not say whether we want to do that to other intrinsics for other targets.

@rnk
Copy link
Collaborator

rnk commented May 2, 2025

follow what we did for _m_prefetchw, but it seems the same idea was tried there but that was also reverted for what seems to be the same exact problem. See #115099 and revert here.

That change was reverted for different reasons. I shouldn't have changed the prototype of _mm_prefetch there, so I'm relanding it here: #138360


So, winnt.h is supposed to be a system header. We already suppress warnings in system headers. Can you elaborate on why you saw a warning and felt you had to back out the last change? If someone is building with -Wsystem-headers, they should expect to see warnings like this. There are other cases like __cpuidex which are mentioned in winnt.h, but don't break the build:

let Header = "intrin.h", Languages = "ALL_MS_LANGUAGES", Attributes = [NoThrow, RequireDeclaration] in {
def _BitScanForward : X86LibBuiltin<"unsigned char(msuint32_t *, msuint32_t)">;
def _BitScanReverse : X86LibBuiltin<"unsigned char(msuint32_t *, msuint32_t)">;
def _ReadWriteBarrier : X86LibBuiltin<"void()">;
def _ReadBarrier : X86LibBuiltin<"void()">;
def _WriteBarrier : X86LibBuiltin<"void()">;
def __cpuid : X86LibBuiltin<"void(int *, int)">;
def __cpuidex : X86LibBuiltin<"void(int *, int, int)">;

Are you sure we need this extra change to suppress the warning?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants