linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Guenter Roeck" <linux@roeck-us.net>,
	"Matthew Auld" <matthew.auld@intel.com>,
	"Arunpravin Paneer Selvam" <Arunpravin.PaneerSelvam@amd.com>,
	"Christian König" <christian.koenig@amd.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 6.8-rc5
Date: Tue, 20 Feb 2024 12:37:13 -0800	[thread overview]
Message-ID: <CAHk-=wg5+Sb3gWGxYumt4Sk9WsfXfqCN_B7uTXfY=jbF0fYBFQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wj6xj_cGmsQK7g=hSfRZZNo-njC+u_1v3dE8fPZtjCBOg@mail.gmail.com>

On Tue, 20 Feb 2024 at 11:57, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> As far as I can tell, 'ps' is never modified, so the compiler should
> be able to just treat it as a constant.

.. oh, and it looks like gcc *does* manage to do that on some targets.
Or at least some versions of gcc do. Because I don't see the build
failure on 32-bit x86 with gcc-13.2.1.

And apparently neither do you (you list csky, openrisc, parisc and xtensa).

I'm not sure why those particular four architectures - maybe it's
about the compiler version, maybe it's just about some basic quality
issues wrt 64-bit support on them - but yes, gcc does do a good job of
untangling that disgusting code in many cases.

The code was still unnecessarily overly complicated, and simply not
using 'u64' is definitely the right fix here. And while gcc did end up
avoding the 64-bit divide/modulus on x86, and did end up noticing that
n_pages was a constant '48', the code generation was still showing all
the signs of doing 64-bit arithmetic for no good reason).

We have good compilers, but that's not an excuse for writing bad code.

              Linus

  parent reply	other threads:[~2024-02-20 20:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-18 21:13 Linux 6.8-rc5 Linus Torvalds
2024-02-19  8:07 ` Build regressions/improvements in v6.8-rc5 Geert Uytterhoeven
2024-02-19  9:54   ` Geert Uytterhoeven
2024-02-19  8:12 ` Geert Uytterhoeven
2024-02-20 19:08 ` Linux 6.8-rc5 Guenter Roeck
2024-02-20 19:57   ` Linus Torvalds
2024-02-20 20:16     ` Linus Torvalds
2024-02-20 23:07       ` Shuah Khan
2024-02-20 20:37     ` Linus Torvalds [this message]
2024-02-20 20:51     ` Geert Uytterhoeven
2024-02-20 21:48     ` Guenter Roeck
2024-02-20 22:02       ` Linus Torvalds

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-=wg5+Sb3gWGxYumt4Sk9WsfXfqCN_B7uTXfY=jbF0fYBFQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=Arunpravin.PaneerSelvam@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=matthew.auld@intel.com \
    /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).