From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 02/10] tools headers compiler: Synchronize compiler_types.h with the kernel sources
Date: Tue, 13 Oct 2026 22:36:59 +0000 [thread overview]
Message-ID: <sashiko-outbox-170585@kernel.org> (raw)
In-Reply-To: <20261013222622.1822619-3-irogers@google.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] tools headers: missing Clang ASM_INPUT_G workarounds may cause bad inline asm
- [Low] tools headers: missing __diag_clang_23 breaks __diag_ignore API
--
commit 2b6bac7c46f78e737bc9e5436ea6f3f62dcfe7d3
Author: Ian Rogers <irogers@google.com>
tools headers compiler: Synchronize compiler_types.h with the kernel sources
Synchronize the non-__KERNEL__ sections of
tools/include/linux/compiler_types.h and
tools/include/linux/compiler-gcc.h with the kernel sources (including
___PASTE/__PASTE, BTF_TYPE_TAG, object-size helpers, asm_goto_output,
ASM_INPUT_*, asm_inline, __typeof_unqual__/__unqual_scalar_typeof,
__signed_scalar_typeof, __native_word, compiletime_assert, and the
__diag pragma helpers required by compiler-context-analysis.h), and
remove the duplicated definitions from tools/include/linux/compiler.h.
> diff --git a/tools/include/linux/compiler-gcc.h b/tools/include/linux/compiler-gcc.h
> index e20f98e14e814..9213691e8e097 100644
> --- a/tools/include/linux/compiler-gcc.h
> +++ b/tools/include/linux/compiler-gcc.h
[ ... ]
> @@ -33,10 +33,59 @@
> #define __packed __attribute__((packed))
> #endif
> #ifndef __noreturn
> -#define __noreturn __attribute__((noreturn))
> +#define __noreturn __attribute__((__noreturn__))
> #endif
> #ifndef __aligned
> #define __aligned(x) __attribute__((aligned(x)))
> #endif
> #define __printf(a, b) __attribute__((format(printf, a, b)))
> #define __scanf(a, b) __attribute__((format(scanf, a, b)))
> +
> +/*
> + * Turn individual warnings and errors on and off locally, depending
> + * on version.
> + */
> +#define __diag_str1(s) #s
> +#define __diag_str(s) __diag_str1(s)
> +
> +#ifdef __clang__
> +#define __diag_clang(version, severity, s) \
> + __diag_clang_ ## version(__diag_clang_ ## severity s)
> +
> +/* Severity used in pragma directives */
> +#define __diag_clang_ignore ignored
> +#define __diag_clang_warn warning
> +#define __diag_clang_error error
> +
> +#define __diag(s) _Pragma(__diag_str(clang diagnostic s))
> +
> +#define __diag_clang_all(s) __diag(s)
> +
> +#define __diag_ignore_all(option, comment) \
> + __diag_clang(all, ignore, option)
> +
[Severity: Low]
Does this missing __diag_clang_23 definition cause a regression in the
__diag_ignore API for Clang?
It looks like __diag_GCC_8 was ported for GCC, but the equivalent
Clang-specific diagnostic ignore request was omitted.
Could this cause a compilation failure due to an undefined macro expansion
when a header uses __diag_ignore(clang, 23, ...) and is included by tools?
> +#define CC_HAS_TYPEOF_UNQUAL (__clang_major__ > 19 || (__clang_major__ == 19 && __clang_minor__ > 0))
> +#else /* !__clang__ */
> +#define __diag_GCC(version, severity, s) \
> + __diag_GCC_ ## version(__diag_GCC_ ## severity s)
> +
[ ... ]
> diff --git a/tools/include/linux/compiler_types.h b/tools/include/linux/compiler_types.h
> index b3adbf5682f02..31e9f7d2a466a 100644
> --- a/tools/include/linux/compiler_types.h
> +++ b/tools/include/linux/compiler_types.h
[ ... ]
> +/*
> + * Clang has trouble with constraints with multiple
> + * alternative behaviors ("g" , "rm" and "=rm").
> + */
> +#ifndef ASM_INPUT_G
> + #define ASM_INPUT_G "g"
> + #define ASM_INPUT_RM "rm"
> + #define ASM_OUTPUT_RM "=rm"
> +#endif
> +
[Severity: Medium]
Will Clang incorrectly use these generic definitions and produce bad codegen
because the Clang-specific overrides ("ir" and "r") were omitted from the
port?
The kernel explicitly overrides these for Clang because of issues with "g"
or "rm" constraints.
Since those overrides are missing here, could tools utilizing kernel arch
headers end up with incorrect inline assembly behavior when built with Clang?
> +#ifdef CONFIG_CC_HAS_ASM_INLINE
> +#define asm_inline asm __inline
> +#else
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261013222622.1822619-1-irogers@google.com?part=2
next prev parent reply other threads:[~2026-10-13 22:36 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-13 18:24 [PATCH v1 00/10] tools/perf: Adopt kernel compiler-context-analysis.h annotations Ian Rogers
2026-10-13 18:24 ` [PATCH v1 01/10] compiler-context-analysis: Avoid unused parameter warning in _context_unsafe_alias() Ian Rogers
2026-10-13 18:30 ` sashiko-bot
2026-10-13 19:44 ` Bart Van Assche
2026-10-13 22:10 ` Ian Rogers
2026-10-13 22:14 ` Bart Van Assche
2026-10-13 22:26 ` Ian Rogers
2026-10-13 22:47 ` Bart Van Assche
2026-10-13 22:59 ` Ian Rogers
2026-10-13 18:24 ` [PATCH v1 02/10] tools headers compiler: Synchronize compiler_types.h with the kernel sources Ian Rogers
2026-10-13 18:33 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 03/10] tools headers: Synchronize linux/compiler-context-analysis.h " Ian Rogers
2026-10-13 18:34 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 04/10] perf mutex: Use kernel style compiler-context-analysis.h annotations Ian Rogers
2026-10-13 18:36 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 05/10] perf build: Enable additional Clang thread-safety flags Ian Rogers
2026-10-13 18:35 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 06/10] perf comm: Add __guarded_by annotations to struct comm_strs Ian Rogers
2026-10-13 18:35 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 07/10] perf dso: Fix unlocked __dsos__add() in vdso and expand lock annotations Ian Rogers
2026-10-13 18:41 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 08/10] perf thread: Expand context analysis annotations to threads and namespaces_lock Ian Rogers
2026-10-13 18:35 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 09/10] perf config, intel-tpebs, env: Add __guarded_by and __must_hold annotations Ian Rogers
2026-10-13 18:42 ` sashiko-bot
2026-10-13 18:24 ` [PATCH v1 10/10] perf maps: Add context analysis annotations Ian Rogers
2026-10-13 18:43 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 00/10] tools/perf: Adopt kernel compiler-context-analysis.h annotations Ian Rogers
2026-10-13 22:26 ` [PATCH v2 01/10] compiler-context-analysis: Avoid unused parameter warning in _context_unsafe_alias() Ian Rogers
2026-10-13 22:30 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 02/10] tools headers compiler: Synchronize compiler_types.h with the kernel sources Ian Rogers
2026-10-13 22:36 ` sashiko-bot [this message]
2026-10-13 22:26 ` [PATCH v2 03/10] tools headers: Synchronize linux/compiler-context-analysis.h " Ian Rogers
2026-10-13 22:34 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 04/10] perf mutex: Use kernel style compiler-context-analysis.h annotations Ian Rogers
2026-10-13 22:42 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 05/10] perf build: Enable additional Clang thread-safety flags Ian Rogers
2026-10-13 22:34 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 06/10] perf comm: Add __guarded_by annotations to struct comm_strs Ian Rogers
2026-10-13 22:36 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 07/10] perf dso: Fix unlocked __dsos__add() in vdso and expand lock annotations Ian Rogers
2026-10-13 22:43 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 08/10] perf thread: Expand context analysis annotations to threads and namespaces_lock Ian Rogers
2026-10-13 22:36 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 09/10] perf config, intel-tpebs, env: Add __guarded_by and __must_hold annotations Ian Rogers
2026-10-13 22:41 ` sashiko-bot
2026-10-13 22:26 ` [PATCH v2 10/10] perf maps: Add context analysis annotations Ian Rogers
2026-10-13 22:38 ` sashiko-bot
2026-10-13 22:52 ` [PATCH v2 00/10] tools/perf: Adopt kernel compiler-context-analysis.h annotations Bart Van Assche
2026-10-13 23:09 ` Ian Rogers
2026-10-13 23:18 ` Bart Van Assche
2026-10-13 23:26 ` Ian Rogers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-170585@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=irogers@google.com \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox