linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pedro Falcato <pedro.falcato@gmail.com>
To: David Laight <david.laight.linux@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Guenter Roeck <linux@roeck-us.net>,
	 David Laight <David.Laight@aculab.com>,
	Arnd Bergmann <arnd@kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	 Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@infradead.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	 Dan Carpenter <dan.carpenter@linaro.org>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>,
	 Mateusz Guzik <mjguzik@gmail.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	 Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	intel-xe@lists.freedesktop.org,  intel-gfx@lists.freedesktop.org,
	David Airlie <airlied@gmail.com>,
	 Simona Vetter <simona@ffwll.ch>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	 Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: Buiild error in i915/xe (was: [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp())
Date: Sat, 18 Jan 2025 23:24:02 +0000	[thread overview]
Message-ID: <CAKbZUD3smtH8YA5jZgg42UP1tHVfSQvVLTfgNuAoKfFsVEXRxg@mail.gmail.com> (raw)
In-Reply-To: <20250118221123.5bb65e64@pumpkin>

On Sat, Jan 18, 2025 at 10:11 PM David Laight
<david.laight.linux@gmail.com> wrote:
>
> On Sat, 18 Jan 2025 13:21:39 -0800
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Sat, 18 Jan 2025 at 09:49, Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > No idea why the compiler would know that the values are invalid.
> >
> > It's not that the compiler knows tat they are invalid, but I bet what
> > happens is in scale() (and possibly other places that do similar
> > checks), which does this:
> >
> >         WARN_ON(source_min > source_max);
> >         ...
> >         source_val = clamp(source_val, source_min, source_max);
> >
> > and the compiler notices that the ordering comparison in the first
> > WARN_ON() is the same as the one in clamp(), so it basically converts
> > the logic to
> >
> >         if (source_min > source_max) {
> >                 WARN(..);
> >                 /* Do the clamp() knowing that source_min > source_max */
> >                 source_val = clamp(source_val, source_min, source_max);
> >         } else {
> >                 /* Do the clamp knowing that source_min <= source_max */
> >                 source_val = clamp(source_val, source_min, source_max);
> >         }
> >
> > (obviously I dropped the other WARN_ON in the conversion, it wasn't
> > relevant for this case).
> >
> > And now that first clamp() case is done with source_min > source_max,
> > and it triggers that build error because that's invalid.
> >
> > So the condition is not statically true in the *source* code, but in
> > the "I have moved code around to combine tests" case it now *is*
> > statically true as far as the compiler is concerned.
>
> Well spotted :-)
>
> One option would be to move the WARN_ON() below the clamp() and
> add an OPTIMISER_HIDE_VAR(source_max) between them.
>
> Or do something more sensible than the WARN().

Given the awful problems we've found with these macros (clamp, min,
max, etc), maybe the best option is to not play these awful games in
general?

These macros seem footgunned to hell just as a way to try to
compensate for C's lack of language features.

-- 
Pedro


  parent reply	other threads:[~2025-01-18 23:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18 19:09 [PATCH next 0/7] minmax.h: Cleanups and minor optimisations David Laight
2024-11-18 19:11 ` [PATCH next 1/7] minmax.h: Add whitespace around operators and after commas David Laight
2024-11-18 19:12 ` [PATCH next 2/7] minmax.h: Update some comments David Laight
2024-11-18 19:12 ` [PATCH next 3/7] minmax.h: Reduce the #define expansion of min(), max() and clamp() David Laight
2024-11-18 19:13 ` [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp() David Laight
2025-01-18 16:13   ` Buiild error in i915/xe (was: [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()) Guenter Roeck
2025-01-18 17:09     ` David Laight
2025-01-18 17:49       ` Guenter Roeck
2025-01-18 18:09         ` David Laight
2025-01-18 18:36           ` Buiild error in i915/xe Guenter Roeck
2025-01-18 21:18             ` David Laight
2025-01-18 21:38               ` Guenter Roeck
2025-01-18 21:21         ` Buiild error in i915/xe (was: [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()) Linus Torvalds
2025-01-18 21:59           ` Buiild error in i915/xe Guenter Roeck
2025-01-18 22:04             ` Linus Torvalds
2025-01-18 22:11           ` Buiild error in i915/xe (was: [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()) David Laight
2025-01-18 22:58             ` Buiild error in i915/xe Guenter Roeck
2025-01-19  9:09               ` David Laight
2025-01-20 10:48                 ` Jani Nikula
2025-01-20 11:15                   ` David Laight
2025-01-20 11:21                     ` Jani Nikula
2025-01-20 14:15                       ` Guenter Roeck
2025-01-20 18:41                         ` David Laight
2025-01-20 18:55                           ` Andy Shevchenko
2025-01-20 19:14                             ` Linus Torvalds
2025-01-21  5:58                               ` Guenter Roeck
2025-01-18 23:24             ` Pedro Falcato [this message]
2024-11-18 19:14 ` [PATCH next 5/7] minmax.h: Move all the clamp() definitions after the min/max() ones David Laight
2024-11-18 19:15 ` [PATCH next 6/7] minmax.h: Simplify the variants of clamp() David Laight
2024-11-22 20:20   ` kernel test robot
2024-11-28 15:05   ` kernel test robot
2024-11-28 15:52     ` David Laight
2024-11-18 19:15 ` [PATCH next 7/7] minmax.h: Remove some #defines that are only expanded once David Laight

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=CAKbZUD3smtH8YA5jZgg42UP1tHVfSQvVLTfgNuAoKfFsVEXRxg@mail.gmail.com \
    --to=pedro.falcato@gmail.com \
    --cc=David.Laight@aculab.com \
    --cc=Jason@zx2c4.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dan.carpenter@linaro.org \
    --cc=david.laight.linux@gmail.com \
    --cc=hch@infradead.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@roeck-us.net \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mjguzik@gmail.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.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