All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.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: Mon, 28 Feb 2022 09:07:03 +0100	[thread overview]
Message-ID: <CAK8P3a3Lv_uSXt9yf-9iOV3hZgV7KvwZjL-gbLTLRgo0UOQguw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com>

On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> 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.

Ok, changed my patch to -gnu11 now.

> 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?

I think all of the options here are equally bad: picking gnu11 means
we use a non-standard default for anything other than gcc-5 and
may get surprised again in the future when we want to change to
a newer version; -std=gnu1x would work as an alias for gnu17 in
all versions including gcc-5 but is already marked as 'deprecated'
in the gcc documentation; and using -std=gnu17 for modern compilers
requires a workaround for gcc-7 and earlier.

Regarding new features from gcc-2x, I think we already use
most of what is listed in https://en.wikipedia.org/wiki/C2x, as
those are all GNU extensions that are valid in modern gnu89 as
well. Newly added features seem to only depend on the compiler
version, e.g. #elifdef works in both clang-13 and gcc-12 with
any -std=gnu?? argument, so picking an earlier standard won't
stop people from breaking the build with older compilers.

         Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.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: Mon, 28 Feb 2022 09:07:03 +0100	[thread overview]
Message-ID: <CAK8P3a3Lv_uSXt9yf-9iOV3hZgV7KvwZjL-gbLTLRgo0UOQguw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com>

On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> 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.

Ok, changed my patch to -gnu11 now.

> 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?

I think all of the options here are equally bad: picking gnu11 means
we use a non-standard default for anything other than gcc-5 and
may get surprised again in the future when we want to change to
a newer version; -std=gnu1x would work as an alias for gnu17 in
all versions including gcc-5 but is already marked as 'deprecated'
in the gcc documentation; and using -std=gnu17 for modern compilers
requires a workaround for gcc-7 and earlier.

Regarding new features from gcc-2x, I think we already use
most of what is listed in https://en.wikipedia.org/wiki/C2x, as
those are all GNU extensions that are valid in modern gnu89 as
well. Newly added features seem to only depend on the compiler
version, e.g. #elifdef works in both clang-13 and gcc-12 with
any -std=gnu?? argument, so picking an earlier standard won't
stop people from breaking the build with older compilers.

         Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.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: Mon, 28 Feb 2022 09:07:03 +0100	[thread overview]
Message-ID: <CAK8P3a3Lv_uSXt9yf-9iOV3hZgV7KvwZjL-gbLTLRgo0UOQguw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com>

On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> 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.

Ok, changed my patch to -gnu11 now.

> 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?

I think all of the options here are equally bad: picking gnu11 means
we use a non-standard default for anything other than gcc-5 and
may get surprised again in the future when we want to change to
a newer version; -std=gnu1x would work as an alias for gnu17 in
all versions including gcc-5 but is already marked as 'deprecated'
in the gcc documentation; and using -std=gnu17 for modern compilers
requires a workaround for gcc-7 and earlier.

Regarding new features from gcc-2x, I think we already use
most of what is listed in https://en.wikipedia.org/wiki/C2x, as
those are all GNU extensions that are valid in modern gnu89 as
well. Newly added features seem to only depend on the compiler
version, e.g. #elifdef works in both clang-13 and gcc-12 with
any -std=gnu?? argument, so picking an earlier standard won't
stop people from breaking the build with older compilers.

         Arnd

_______________________________________________
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: Arnd Bergmann <arnd@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.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: Mon, 28 Feb 2022 09:07:03 +0100	[thread overview]
Message-ID: <CAK8P3a3Lv_uSXt9yf-9iOV3hZgV7KvwZjL-gbLTLRgo0UOQguw@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whWbENRz-vLY6vpESDLj6kGUTKO3khGtVfipHqwewh2HQ@mail.gmail.com>

On Sun, Feb 27, 2022 at 11:36 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> 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.

Ok, changed my patch to -gnu11 now.

> 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?

I think all of the options here are equally bad: picking gnu11 means
we use a non-standard default for anything other than gcc-5 and
may get surprised again in the future when we want to change to
a newer version; -std=gnu1x would work as an alias for gnu17 in
all versions including gcc-5 but is already marked as 'deprecated'
in the gcc documentation; and using -std=gnu17 for modern compilers
requires a workaround for gcc-7 and earlier.

Regarding new features from gcc-2x, I think we already use
most of what is listed in https://en.wikipedia.org/wiki/C2x, as
those are all GNU extensions that are valid in modern gnu89 as
well. Newly added features seem to only depend on the compiler
version, e.g. #elifdef works in both clang-13 and gcc-12 with
any -std=gnu?? argument, so picking an earlier standard won't
stop people from breaking the build with older compilers.

         Arnd

  reply	other threads:[~2022-02-28  8:07 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
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 [this message]
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=CAK8P3a3Lv_uSXt9yf-9iOV3hZgV7KvwZjL-gbLTLRgo0UOQguw@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=alexs@kernel.org \
    --cc=arnd@arndb.de \
    --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 \
    --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.