All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org,
	Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH 1/2] Kbuild: enable -fms-extensions
Date: Wed, 22 Oct 2025 18:15:05 +0200	[thread overview]
Message-ID: <20251022161505.GA1226098@ax162> (raw)
In-Reply-To: <20251020142228.1819871-2-linux@rasmusvillemoes.dk>

On Mon, Oct 20, 2025 at 04:22:27PM +0200, Rasmus Villemoes wrote:
> Once in a while, it turns out that enabling -fms-extensions could
> allow some slightly prettier code. But every time it has come up, the
> code that had to be used instead has been deemed "not too awful" and
> not worth introducing another compiler flag for.
> 
> That's probably true for each individual case, but then it's somewhat
> of a chicken/egg situation.
> 
> If we just "bite the bullet" as Linus says and enable it once and for
> all, it is available whenever a use case turns up, and no individual
> case has to justify it.
> 
> A lore.kernel.org search provides these examples:
> 
> - https://lore.kernel.org/lkml/200706301813.58435.agruen@suse.de/
> - https://lore.kernel.org/lkml/20180419152817.GD25406@bombadil.infradead.org/
> - https://lore.kernel.org/lkml/170622208395.21664.2510213291504081000@noble.neil.brown.name/
> - https://lore.kernel.org/lkml/87h6475w9q.fsf@prevas.dk/
> - https://lore.kernel.org/lkml/CAHk-=wjeZwww6Zswn6F_iZTpUihTSNKYppLqj36iQDDhfntuEw@mail.gmail.com/
> 
> Undoubtedly, there are more places in the code where this could also
> be used but where -fms-extensions just didn't come up in any
> discussion.
> 
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
>  Makefile | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index d14824792227..ef6f23ee8e7f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1061,6 +1061,15 @@ NOSTDINC_FLAGS += -nostdinc
>  # perform bounds checking.
>  KBUILD_CFLAGS += $(call cc-option, -fstrict-flex-arrays=3)
>  
> +# Allow including a tagged struct or union anonymously in another struct/union.
> +KBUILD_CFLAGS += -fms-extensions
> +
> +# For clang, the -fms-extensions flag is apparently not enough to
> +# express one's intention to make use of those extensions.
> +ifdef CONFIG_CC_IS_CLANG
> +KBUILD_CFLAGS += -Wno-microsoft-anon-tag
> +endif

I think this should go in the first 'ifdef CONFIG_CC_IS_CLANG' block in
scripts/Makefile.extrawarn below '-Wno-gnu' with a comment that is
similar in nature, which could even be combined like

  # The kernel builds with '-std-gnu11' and '-fms-extensions' so the use
  # of GNU and Microsoft extensions is acceptable.

Other than that, this seems fine to me.

>  # disable invalid "can't wrap" optimizations for signed / pointers
>  KBUILD_CFLAGS	+= -fno-strict-overflow
>  
> -- 
> 2.51.0
> 

  reply	other threads:[~2025-10-22 16:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-20 14:22 [PATCH 0/2] Kbuild: enable -fms-extensions, make btrfs the first user Rasmus Villemoes
2025-10-20 14:22 ` [PATCH 1/2] Kbuild: enable -fms-extensions Rasmus Villemoes
2025-10-22 16:15   ` Nathan Chancellor [this message]
2025-10-22 20:35     ` Rasmus Villemoes
2025-10-22 21:11       ` Nathan Chancellor
2025-10-23 12:40         ` Nathan Chancellor
2025-10-23 14:17           ` Dave Kleikamp
2025-10-23 16:45             ` Nathan Chancellor
2025-10-20 14:22 ` [PATCH 2/2] btrfs: send: make use of -fms-extensions for defining struct fs_path Rasmus Villemoes
2025-10-20 19:48   ` Linus Torvalds
2025-10-22  5:24     ` David Sterba
2025-10-22  5:30 ` [PATCH 0/2] Kbuild: enable -fms-extensions, make btrfs the first user David Sterba
2025-10-22 16:17   ` Nathan Chancellor

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=20251022161505.GA1226098@ax162 \
    --to=nathan@kernel.org \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.