From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Linus Torvalds <torvalds@linux-foundation.org>,
David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
linux-kbuild@vger.kernel.org,
Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: [PATCH 1/2] Kbuild: enable -fms-extensions
Date: Mon, 20 Oct 2025 16:22:27 +0200 [thread overview]
Message-ID: <20251020142228.1819871-2-linux@rasmusvillemoes.dk> (raw)
In-Reply-To: <20251020142228.1819871-1-linux@rasmusvillemoes.dk>
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
+
# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS += -fno-strict-overflow
--
2.51.0
next prev parent reply other threads:[~2025-10-20 14:22 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 ` Rasmus Villemoes [this message]
2025-10-22 16:15 ` [PATCH 1/2] Kbuild: enable -fms-extensions Nathan Chancellor
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=20251020142228.1819871-2-linux@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=nathan@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox