All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	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>,
	"pedro.falcato@gmail.com" <pedro.falcato@gmail.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
Date: Sun, 19 Jan 2025 09:09:35 +0000	[thread overview]
Message-ID: <20250119090935.7c690f85@pumpkin> (raw)
In-Reply-To: <f3939490-0f55-410f-81fe-0e9f03874546@roeck-us.net>

On Sat, 18 Jan 2025 14:58:48 -0800
Guenter Roeck <linux@roeck-us.net> wrote:

> On 1/18/25 14:11, David Laight 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().
> > Perhaps return target_min on any such errors?
> >   
> 
> This helps:
> 
> -       WARN_ON(source_min > source_max);
> -       WARN_ON(target_min > target_max);
> -
>          /* defensive */
>          source_val = clamp(source_val, source_min, source_max);
> 
> +       WARN_ON(source_min > source_max);
> +       WARN_ON(target_min > target_max);

That is a 'quick fix' ...

Much better would be to replace the WARN() with (say):
	if (target_min >= target_max)
		return target_min;
	if (source_min >= source_max)
		return target_min + (target_max - target_min)/2;
So that the return values are actually in range (in as much as one is defined).
Note that the >= cpmparisons also remove a divide by zero.

	David

> 
> Guenter
> 


  reply	other threads:[~2025-01-21 13:31 UTC|newest]

Thread overview: 45+ 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 [this message]
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             ` Buiild error in i915/xe (was: [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()) Pedro Falcato
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
2025-01-18 17:56 ` ✓ CI.Patch_applied: success for Buiild error in i915/xe (was: [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()) Patchwork
2025-01-18 17:56 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-18 17:57 ` ✓ CI.KUnit: success " Patchwork
2025-01-18 18:16 ` ✓ CI.Build: " Patchwork
2025-01-18 18:18 ` ✓ CI.Hooks: " Patchwork
2025-01-18 18:19 ` ✓ CI.checksparse: " Patchwork
2025-01-18 18:37 ` ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2025-01-18 18:46 ` ✓ Xe.CI.BAT: success " Patchwork
2025-01-18 18:51 ` ✗ i915.CI.BAT: failure " Patchwork
2025-01-18 20:30 ` ✗ Xe.CI.Full: " Patchwork
2025-01-18 22:08 ` ✗ Fi.CI.BUILD: failure for Buiild error in i915/xe (was: [PATCH next 4/7] minmax.h: Use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()) (rev2) Patchwork
2025-01-18 22:10 ` ✗ CI.Patch_applied: " Patchwork

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=20250119090935.7c690f85@pumpkin \
    --to=david.laight.linux@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=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=pedro.falcato@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 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.