Re: [PATCH next] minmax.h: Use auto for variables in __minmax_array()

[David Laight <david.laight.linux@gmail.com>]

On Fri, 6 Feb 2026 14:41:35 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Fri,  6 Feb 2026 22:25:54 +0000 david.laight.linux@gmail.com wrote:
> 
> > From: David Laight <david.laight.linux@gmail.com>
> > 
> > While 'auto __element = _array[--__len]' should remove 'const',
> > gcc prior to version 11 are buggy and retain it.  
> 
> With what effect?

If you have:
int f(const int x)
{
	auto y = x;
	y++;
	return y;
}
gcc prior to 11.0 error that y is const.
So in this case the loop can't change __element.

The constness is also kept by 'auto y = +x' which does integer promotion
(useful for converting enums) and both -x and ~x.

> > 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/ ?

Actually s/Type/the/

> > 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?

Mainly unqual_scalar_typeof() being horrid.
There is an ongoing long thread about its use in the arm64 LTO READ_ONCE().
Newer compilers do have a builtin, and there are some shorter alternatives
that work in some places.
But here is just isn't needed.
So one less place to check.

I did mean to copy the main contributers to that thread, but forgot.

	David