[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5a129d04e0b84b48ba6c5189a047ac8f@AcuMS.aculab.com>
Date: Thu, 25 Jul 2024 09:00:41 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Linus Torvalds' <torvalds@...uxfoundation.org>, Arnd Bergmann
<arnd@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Matthew
Wilcox" <willy@...radead.org>, Christoph Hellwig <hch@...radead.org>, "Andrew
Morton" <akpm@...ux-foundation.org>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Dan Carpenter
<dan.carpenter@...aro.org>, "Jason A . Donenfeld" <Jason@...c4.com>,
"pedro.falcato@...il.com" <pedro.falcato@...il.com>, Mateusz Guzik
<mjguzik@...il.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: RE: [PATCH 4/7] minmax: Simplify signedness check
From: Linus Torvalds
> Sent: 24 July 2024 21:03
>
> On Wed, 24 Jul 2024 at 09:49, Arnd Bergmann <arnd@...nel.org> wrote:
> >
> > I don't understand why this return '0' for unsigned types,
> > shouldn't this be
> >
> > ((is_unsigned_type(typeof(x)) ? 1 : __if_constexpr(x, (x) + 0, -1)) >= 0)
>
> Yes, that looks more logical.
The condition is '>= 0' so it doesn't matter if it is '1' or '0'.
> Plus why do that "__if_constexpr(x, (x) + 0, -1)) >= 0)" when it would
> appear to be more logical to move the comparison inside, ie
>
> __if_constexpr(x, (x) >= 0, 0)
That gives a 'comparison of unsigned type against 0 is always true' warning.
(The compiler generates that for code in the unused branches of both
__builtin_choose_expr() and _Generic().)
Moving the comparison to the outer level stops all such compiler warnings.
> but I also don't see why that "+ 0" existed in the original. So
> there's presumably something I'm missing.
IIRC it was there to convert a 'bool' to 'int'.
Somewhere the is a max(bool,bool) that could just be |.
If may not be needed now the expansion is '(cond ? 0 : bool) >= 0'
since the 'bool' picks up an (int) cast from the result of ?:.
David
> I do get the feeling that the problem came from us being much too
> clever with out min/max macros, and now this series is doubling down
> instead of saying "it wasn't really worth it".
>
> Linus
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists