linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Laight <david.laight.linux@gmail.com>,
	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: Sat, 18 Jan 2025 13:59:36 -0800	[thread overview]
Message-ID: <0f28a0b7-c24d-47d8-92f0-8957207ea309@roeck-us.net> (raw)
In-Reply-To: <CAHk-=whAxUvW-APU42yWfCKHF5NhPLoTida9Jo=A9ZGGgjb18Q@mail.gmail.com>

On 1/18/25 13:21, Linus Torvalds 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.
> 

Yes, turns out I can reproduce the problem by adding WARN_ON() ahead
of similar clamp() calls (see below). However, I can only reproduce it
with gcc 13.3 for parisc. I don't see the problem with other cross compilers
(I tried arm, powerpc, and loongarch64). Compilers are weird :-(.

I am not sure what to do here. That kind of problem seems difficult
to avoid, and I am sure we will hit it again elsewhere. Should I declare
gcc 13.x off limits for parisc builds ?

Guenter

---
diff --git a/drivers/input/mousedev.c b/drivers/input/mousedev.c
index 505c562a5daa..71c0da31a9d2 100644
--- a/drivers/input/mousedev.c
+++ b/drivers/input/mousedev.c
@@ -179,6 +179,7 @@ static void mousedev_abs_event(struct input_dev *dev, struct mousedev *mousedev,
                 if (size == 0)
                         size = xres ? : 1;

+               WARN_ON(min > max);
                 value = clamp(value, min, max);

                 mousedev->packet.x = ((value - min) * xres) / size;



  reply	other threads:[~2025-01-18 21:59 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           ` Guenter Roeck [this message]
2025-01-18 22:04             ` Buiild error in i915/xe 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             ` 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

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=0f28a0b7-c24d-47d8-92f0-8957207ea309@roeck-us.net \
    --to=linux@roeck-us.net \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox