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;
next prev parent 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