All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev,  Jonathan Corbet <corbet@lwn.net>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>,  Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	 Nick Desaulniers <ndesaulniers@google.com>,
	 "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 intel-gfx <intel-gfx@lists.freedesktop.org>,
	 dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org,  linux-staging@lists.linux.dev,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
Date: Sun, 27 Feb 2022 14:36:02 -0800	[thread overview]
Message-ID: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com> (raw)
In-Reply-To: <20220227215408.3180023-1-arnd@kernel.org>

On Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> Since the differences between gnu99, gnu11 and gnu17 are fairly minimal
> and mainly impact warnings at the -Wpedantic level that the kernel
> never enables, the easiest way is to just leave out the -std=gnu89
> argument entirely, and rely on the compiler default language setting,
> which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported
> versions of gcc or clang.

Honestly, I'd rather keep the C version we support as some explicit
thing, instead of "whatever the installed compiler is".

Not only do I suspect that you can set it in gcc spec files (so the
standard version might actually be site-specific, not compiler version
specific), but particularly with clang, I'd like that "GNU extensions
enabled" to be explicit. Yes, maybe it's the default, but let's make
sure.

The C version level has traditionally had a lot of odd semantic
meaning details - you mention "inline", others have existed. So it's
not just the actual new features that some C version implements, it's
those kind of "same syntax, different meaning" issues. I really don't
think that's something we want in the kernel any more.

Been there, done that, and we did the explicit standards level for a reason.

It may be true that c99/c11/c17 are all very similar, and don't have
those issues. Or maybe they do.

And I don't want somebody with a newer compiler version to not notice
that he or she ended up using a c17 feature, just because _that_
compiler supported it, and then other people get build errors because
their compilers use gnu11 instead by default.

Put another way: I see absolutely no upside to allowing different
users using higher/lower versions of the standard. There are only
downsides.

If gnu11 is supported by gcc-5.1 and up, and all the relevant clang
versions, then let's just pick that.

And if there are any possible future advantages to gnu17 (or eventual
gnu2x versions), let's document those, so that we can say "once our
compiler version requirements go up sufficiently, we'll move to gnuXX
because we want to take advantage of YY".

Please?

                   Linus

                   Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Michal Marek <michal.lkml@markovi.net>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
	linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org, Alex Shi <alexs@kernel.org>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
Date: Sun, 27 Feb 2022 14:36:02 -0800	[thread overview]
Message-ID: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com> (raw)
In-Reply-To: <20220227215408.3180023-1-arnd@kernel.org>

On Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> Since the differences between gnu99, gnu11 and gnu17 are fairly minimal
> and mainly impact warnings at the -Wpedantic level that the kernel
> never enables, the easiest way is to just leave out the -std=gnu89
> argument entirely, and rely on the compiler default language setting,
> which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported
> versions of gcc or clang.

Honestly, I'd rather keep the C version we support as some explicit
thing, instead of "whatever the installed compiler is".

Not only do I suspect that you can set it in gcc spec files (so the
standard version might actually be site-specific, not compiler version
specific), but particularly with clang, I'd like that "GNU extensions
enabled" to be explicit. Yes, maybe it's the default, but let's make
sure.

The C version level has traditionally had a lot of odd semantic
meaning details - you mention "inline", others have existed. So it's
not just the actual new features that some C version implements, it's
those kind of "same syntax, different meaning" issues. I really don't
think that's something we want in the kernel any more.

Been there, done that, and we did the explicit standards level for a reason.

It may be true that c99/c11/c17 are all very similar, and don't have
those issues. Or maybe they do.

And I don't want somebody with a newer compiler version to not notice
that he or she ended up using a c17 feature, just because _that_
compiler supported it, and then other people get build errors because
their compilers use gnu11 instead by default.

Put another way: I see absolutely no upside to allowing different
users using higher/lower versions of the standard. There are only
downsides.

If gnu11 is supported by gcc-5.1 and up, and all the relevant clang
versions, then let's just pick that.

And if there are any possible future advantages to gnu17 (or eventual
gnu2x versions), let's document those, so that we can say "once our
compiler version requirements go up sufficiently, we'll move to gnuXX
because we want to take advantage of YY".

Please?

                   Linus

                   Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev,  Jonathan Corbet <corbet@lwn.net>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Alex Shi <alexs@kernel.org>,  Hu Haowen <src.res@email.cn>,
	Michal Marek <michal.lkml@markovi.net>,
	 Nick Desaulniers <ndesaulniers@google.com>,
	 "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	 Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 intel-gfx <intel-gfx@lists.freedesktop.org>,
	 dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org,  linux-staging@lists.linux.dev,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
Date: Sun, 27 Feb 2022 14:36:02 -0800	[thread overview]
Message-ID: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com> (raw)
In-Reply-To: <20220227215408.3180023-1-arnd@kernel.org>

On Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> Since the differences between gnu99, gnu11 and gnu17 are fairly minimal
> and mainly impact warnings at the -Wpedantic level that the kernel
> never enables, the easiest way is to just leave out the -std=gnu89
> argument entirely, and rely on the compiler default language setting,
> which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported
> versions of gcc or clang.

Honestly, I'd rather keep the C version we support as some explicit
thing, instead of "whatever the installed compiler is".

Not only do I suspect that you can set it in gcc spec files (so the
standard version might actually be site-specific, not compiler version
specific), but particularly with clang, I'd like that "GNU extensions
enabled" to be explicit. Yes, maybe it's the default, but let's make
sure.

The C version level has traditionally had a lot of odd semantic
meaning details - you mention "inline", others have existed. So it's
not just the actual new features that some C version implements, it's
those kind of "same syntax, different meaning" issues. I really don't
think that's something we want in the kernel any more.

Been there, done that, and we did the explicit standards level for a reason.

It may be true that c99/c11/c17 are all very similar, and don't have
those issues. Or maybe they do.

And I don't want somebody with a newer compiler version to not notice
that he or she ended up using a c17 feature, just because _that_
compiler supported it, and then other people get build errors because
their compilers use gnu11 instead by default.

Put another way: I see absolutely no upside to allowing different
users using higher/lower versions of the standard. There are only
downsides.

If gnu11 is supported by gcc-5.1 and up, and all the relevant clang
versions, then let's just pick that.

And if there are any possible future advantages to gnu17 (or eventual
gnu2x versions), let's document those, so that we can say "once our
compiler version requirements go up sufficiently, we'll move to gnuXX
because we want to take advantage of YY".

Please?

                   Linus

                   Linus

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Michal Marek <michal.lkml@markovi.net>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>, Jonathan Corbet <corbet@lwn.net>,
	linux-staging@lists.linux.dev,
	Masahiro Yamada <masahiroy@kernel.org>,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	greybus-dev@lists.linaro.org, Alex Shi <alexs@kernel.org>,
	Federico Vaga <federico.vaga@vaga.pv.it>,
	Hu Haowen <src.res@email.cn>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	linux-doc-tw-discuss@lists.sourceforge.net,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [Intel-gfx] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
Date: Sun, 27 Feb 2022 14:36:02 -0800	[thread overview]
Message-ID: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com> (raw)
In-Reply-To: <20220227215408.3180023-1-arnd@kernel.org>

On Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> Since the differences between gnu99, gnu11 and gnu17 are fairly minimal
> and mainly impact warnings at the -Wpedantic level that the kernel
> never enables, the easiest way is to just leave out the -std=gnu89
> argument entirely, and rely on the compiler default language setting,
> which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported
> versions of gcc or clang.

Honestly, I'd rather keep the C version we support as some explicit
thing, instead of "whatever the installed compiler is".

Not only do I suspect that you can set it in gcc spec files (so the
standard version might actually be site-specific, not compiler version
specific), but particularly with clang, I'd like that "GNU extensions
enabled" to be explicit. Yes, maybe it's the default, but let's make
sure.

The C version level has traditionally had a lot of odd semantic
meaning details - you mention "inline", others have existed. So it's
not just the actual new features that some C version implements, it's
those kind of "same syntax, different meaning" issues. I really don't
think that's something we want in the kernel any more.

Been there, done that, and we did the explicit standards level for a reason.

It may be true that c99/c11/c17 are all very similar, and don't have
those issues. Or maybe they do.

And I don't want somebody with a newer compiler version to not notice
that he or she ended up using a c17 feature, just because _that_
compiler supported it, and then other people get build errors because
their compilers use gnu11 instead by default.

Put another way: I see absolutely no upside to allowing different
users using higher/lower versions of the standard. There are only
downsides.

If gnu11 is supported by gcc-5.1 and up, and all the relevant clang
versions, then let's just pick that.

And if there are any possible future advantages to gnu17 (or eventual
gnu2x versions), let's document those, so that we can say "once our
compiler version requirements go up sufficiently, we'll move to gnuXX
because we want to take advantage of YY".

Please?

                   Linus

                   Linus

  reply	other threads:[~2022-02-27 22:41 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-27 21:52 [PATCH] Kbuild: remove -std=gnu89 from compiler arguments Arnd Bergmann
2022-02-27 21:52 ` [Intel-gfx] " Arnd Bergmann
2022-02-27 21:52 ` Arnd Bergmann
2022-02-27 21:52 ` Arnd Bergmann
2022-02-27 22:36 ` Linus Torvalds [this message]
2022-02-27 22:36   ` [Intel-gfx] " Linus Torvalds
2022-02-27 22:36   ` Linus Torvalds
2022-02-27 22:36   ` Linus Torvalds
2022-02-28  8:07   ` Arnd Bergmann
2022-02-28  8:07     ` [Intel-gfx] " Arnd Bergmann
2022-02-28  8:07     ` Arnd Bergmann
2022-02-28  8:07     ` Arnd Bergmann
2022-02-27 23:04 ` [greybus-dev] " Alex Elder
2022-02-27 23:04   ` [Intel-gfx] " Alex Elder
2022-02-27 23:04   ` Alex Elder
2022-02-27 23:04   ` Alex Elder
2022-02-27 23:11   ` Linus Torvalds
2022-02-27 23:11     ` Linus Torvalds
2022-02-27 23:11     ` Linus Torvalds
2022-02-27 23:11     ` [Intel-gfx] " Linus Torvalds
2022-02-27 23:57     ` Alex Elder
2022-02-27 23:57       ` [Intel-gfx] " Alex Elder
2022-02-27 23:57       ` Alex Elder
2022-02-27 23:57       ` Alex Elder
2022-02-28  8:11   ` Arnd Bergmann
2022-02-28  8:11     ` [Intel-gfx] " Arnd Bergmann
2022-02-28  8:11     ` Arnd Bergmann
2022-02-28  8:11     ` Arnd Bergmann
2022-02-28  0:14 ` John Stoffel
2022-02-28  0:14   ` [Intel-gfx] " John Stoffel
2022-02-28  0:14   ` John Stoffel
2022-02-28  0:14   ` John Stoffel
2022-02-28  8:11   ` Arnd Bergmann
2022-02-28  8:11     ` [Intel-gfx] " Arnd Bergmann
2022-02-28  8:11     ` Arnd Bergmann
2022-02-28  8:11     ` Arnd Bergmann
2022-02-28 12:02 ` Christoph Hellwig
2022-02-28 12:02   ` Christoph Hellwig
2022-02-28 12:02   ` [Intel-gfx] " Christoph Hellwig
2022-02-28 21:07 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-02-28 21:36 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-01  6:20 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2022-02-28 17:36 [PATCH] " kernel test robot

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='CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=alexs@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=federico.vaga@vaga.pv.it \
    --cc=greybus-dev@lists.linaro.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-doc-tw-discuss@lists.sourceforge.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=ndesaulniers@google.com \
    --cc=src.res@email.cn \
    /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.