xen/compiler: Clang 14 and later understands attribute((error))

[PATCH] xen/compiler: Clang 14 and later understands attribute((error))

Andrew Cooper posted 1 patch 1 year, 2 months ago

Download mbox

Test gitlab-ci failed

Patches applied successfully (tree, apply log)
git fetch https://gitlab.com/xen-project/patchew/xen tags/patchew/20230223122245.2557228-1-andrew.cooper3@citrix.com

xen/include/xen/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Expand all Fold all

[PATCH] xen/compiler: Clang 14 and later understands attribute((error))

Posted by Andrew Cooper 1 year, 2 months ago

Adjust the ifdefary for `nocall`.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <JBeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Wei Liu <wl@xen.org>
---
 xen/include/xen/compiler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index a5631303348b..7d7ae2e5e4d9 100644
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -31,7 +31,7 @@
 
 #define __weak        __attribute__((__weak__))
 
-#if !defined(__clang__)
+#if !CONFIG_CC_IS_CLANG || CONFIG_CLANG_VERSION >= 140000
 # define nocall       __attribute__((__error__("Nonstandard ABI")))
 #else
 # define nocall
-- 
2.30.2

Re: [PATCH] xen/compiler: Clang 14 and later understands attribute((error))

Posted by Jan Beulich 1 year, 2 months ago

On 23.02.2023 13:22, Andrew Cooper wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -31,7 +31,7 @@
>  
>  #define __weak        __attribute__((__weak__))
>  
> -#if !defined(__clang__)
> +#if !CONFIG_CC_IS_CLANG || CONFIG_CLANG_VERSION >= 140000

Hmm, for the sake of getting the functional change in,
Reviewed-by: Jan Beulich <jbeulich@suse.com>
but this clearly is against the Kconfig usage proposal: Following that,
such conditionals should not reference CONFIG_*, as the .config may
have been generated not only with a different Clang version, but also
with gcc instead of Clang. While there were a couple of comments, no
counter proposal appeared so far, there was one explicit agreement
with the proposal, and the requested patch demonstrating the
intentions wasn't commented on either. One might conclude that as per
our lazy consensus approach the proposal holds, and no such new uses
violating its principles should be introduced. The more that the same
can easily be expressed differently.

Jan