linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christophe de Dinechin <christophe@dinechin.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Christophe de Dinechin <dinechin@redhat.com>,
	trivial@kernel.org, Ben Segall <bsegall@google.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	virtualization@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org,
	Zhen Lei <thunder.leizhen@huawei.com>,
	Juri Lelli <juri.lelli@redhat.com>
Subject: Re: [PATCH 1/3] sched/headers: Fix compilation error with GCC 12
Date: Mon, 25 Apr 2022 16:23:17 +0200	[thread overview]
Message-ID: <6139D443-68FC-4A8D-9401-4FA5CDA158AD@dinechin.org> (raw)
In-Reply-To: <20220414133050.b820fa45d42de4cfc24db82b@linux-foundation.org>



> On 14 Apr 2022, at 22:30, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> On Thu, 14 Apr 2022 17:21:01 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> 
>>> +/* The + 1 below places the pointers within the range of their array */
>>> #define for_class_range(class, _from, _to) \
>>> -	for (class = (_from); class != (_to); class--)
>>> +	for (class = (_from); class + 1 != (_to) + 1; class--)
>> 
>> Urgh, so now we get less readable code, just because GCC is being
>> stupid?
>> 
>> What's wrong with negative array indexes? memory is memory, stuff works.
> 
> What's more, C is C.  Glorified assembly language in which people do odd
> stuff.

Notably since the advent of clang, we moved a bit beyond glorified assembly language.
There is no 1 on 1 correspondence between what you write and the generated
assembly anymore, by a long shot. I’m sure you know that ;-), but that’s an
opportunity to plug Jason Turner’s conference on writing a C64 pong game using C++17
(https://www.youtube.com/watch?v=zBkNBP00wJE). That demonstrates,
in a funny way, just how far compilers go these days to massage your code.

> 
> But this is presumably a released gcc version and we need to do
> something.  And presumably, we need to do a backportable something, so
> people can compile older kernels with gcc-12.

Hmm, I must admit I had not considered the backporting implications.

> 
> Is it possible to suppress just this warning with a gcc option? And if
> so, are we confident that this warning will never be useful in other
> places in the kernel?

I would advise against it, and not just because of warnings.

With GCC’s ability to track pointers to individual C objects, you can expect
that they will soon start optimising based on that collected knowledge.

An example of useful optimisation based on that knowledge is to
avoid memory reloads, The idea is that a write in array B[] does
not force you to reload all data you already fetched from array A[].
But that requires the compiler to prove that pointers to A[] stay in A[]
and that you don’t purposely build negative indexes from B[] or
anything weird like that.


> If no||no then we'll need to add workarounds such as these?

It is definitely possible to silence that warning. I would still recommend
adding this kind of changes, which I would personally describe more as
“accurate description intended of memory accesses” rather than “workarounds”.
To me, it’s on the same level as putting memory fences, for example.

> 


  parent reply	other threads:[~2022-04-25 14:23 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-14 15:08 [PATCH 0/3] trivial: Fix several compilation errors/warnings with GCC12 Christophe de Dinechin
2022-04-14 15:08 ` [PATCH 1/3] sched/headers: Fix compilation error with GCC 12 Christophe de Dinechin
2022-04-14 15:21   ` Peter Zijlstra
2022-04-14 20:30     ` Andrew Morton
2022-04-17 15:52       ` Peter Zijlstra
2022-04-20 18:45         ` Kees Cook
2022-04-21  7:32           ` Peter Zijlstra
2022-04-25 14:23       ` Christophe de Dinechin [this message]
2022-04-17 13:27     ` David Laight
2022-04-25 14:07     ` Christophe de Dinechin
2022-05-19 11:16       ` Peter Zijlstra
2022-04-14 15:08 ` [PATCH 2/3] nodemask.h: Fix compilation error with GCC12 Christophe de Dinechin
2022-04-14 15:23   ` Peter Zijlstra
2022-04-14 15:08 ` [PATCH 3/3] virtio-pci: Use cpumask_available to fix compilation error Christophe de Dinechin
2022-04-15  8:48   ` Michael S. Tsirkin
2022-04-28  9:48     ` Christophe Marie Francois Dupont de Dinechin
2022-04-28 11:06       ` Michael S. Tsirkin
2022-05-15 21:24 ` [PATCH 0/3] trivial: Fix several compilation errors/warnings with GCC12 Davidlohr Bueso

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=6139D443-68FC-4A8D-9401-4FA5CDA158AD@dinechin.org \
    --to=christophe@dinechin.org \
    --cc=akpm@linux-foundation.org \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=dinechin@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=thunder.leizhen@huawei.com \
    --cc=trivial@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=virtualization@lists.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;
as well as URLs for NNTP newsgroup(s).