[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20260206144135.89b1edb4f25fed21b7a1ccc9@linux-foundation.org>
Date: Fri, 6 Feb 2026 14:41:35 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: david.laight.linux@...il.com
Cc: Peter Anvin <hpa@...or.com>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Arnd Bergmann <arnd@...nel.org>,
Christoph Hellwig <hch@...radead.org>, "Jason A . Donenfeld"
<Jason@...c4.com>, Herve Codina <herve.codina@...tlin.com>, Linus Torvalds
<torvalds@...ux-foundation.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH next] minmax.h: Use auto for variables in
__minmax_array()
On Fri, 6 Feb 2026 22:25:54 +0000 david.laight.linux@...il.com wrote:
> From: David Laight <david.laight.linux@...il.com>
>
> While 'auto __element = _array[--__len]' should remove 'const',
> gcc prior to version 11 are buggy and retain it.
With what effect?
> However forcing an integer promotion by adding zero does work.
>
> Promoting signed/unsigned char and short to int doesn't matter here,
> that happens as soon as the value is used.
>
> Type type of the result (for char/short arrays) changes, but the value
s/Type type/Type/ ?
> will always be promoted to int before it is used (for any purpose) so
> it isn't even worth casting the type back - all that is likely to do
> is make the compiler explicitly mask it to 8/16 bits before it is
> immediately promoted back to int.
I'm not understanding the motivation for this change. Is there some
compilation issue to be addressed?
Powered by blists - more mailing lists