From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D227B310763 for ; Sat, 7 Feb 2026 10:25:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770459955; cv=none; b=hth/bf/QTZ0Q7HbZw0VcLc2KHEeJKUqvNuHM1HKZkvOJvwH0xfv7p1XMRyik2W6Ljnokv7LlfKynwcO94Qbns0W61RyaZpnI+ZCFE9t6U0gzfPdvMYf155El9bYQavn7PajQIozmKA2d6IGVvl7oJhk05lXQMnCGeOjhiRZZmr4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770459955; c=relaxed/simple; bh=uJc6yo5jhFnXi7E5nXys7/Ug19ViJD9vOmy7ugQkZtw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NAq2W5D7VeJxJin8vQbRNu152E6Cp/ptB+EdBYN7/XfD//k7BYaqzt8K2pNmEHtK55d2XydvrBzQoWSTWc1/QembECCWG6QFTnkWeIJIm+1uI0CWoSfSK6LXmgOqOMbsEHPa1ivVs2m6EP0kJgZIeJLIWjwrWOb6LsdJr1XM9/k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=a/CzWbJ7; arc=none smtp.client-ip=209.85.221.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="a/CzWbJ7" Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-436234ef0f0so1612849f8f.1 for ; Sat, 07 Feb 2026 02:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770459953; x=1771064753; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=s6OV5K42t2wGUf+wNellcGUN7zjMSuOd9WkZ9eTsUno=; b=a/CzWbJ7eGtiVkaBwfA190rLphaPwr+Zku8uB6wsS3YOxf7bs7kSqM1XwXPoyGpp1O ah1rh7e/uz8calhgR43P2n08HMU3nOSmmffCHAc7BOgnxn7FEhaM15yFZeSjozTHFMzs awZzztDZd5HcRHzwSjx9GZ5V2Jf3M6fF8MAdz5ARHkdsfty2aPocZEnBfkaNhBItX5UU +kDCZC9GA1fZexmpKlQBZKVDt+nGmnxn/Tiso1tB96ZUnTm0Hb1flTrqC5zPmJkPRFjf tvXqZCD8yLlhuoKX+a7qpKJwJLOe37jpXsAjZFcnnUqtgsf9mDMv+xsN4eWUDKz2urt1 ZGNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770459953; x=1771064753; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=s6OV5K42t2wGUf+wNellcGUN7zjMSuOd9WkZ9eTsUno=; b=erWHYu73Vx8JssaVUrDVC3tBAYoymhxdFpiAIb3PzKsFT2xTc37whQGS9dd1dLfhhx zuc2AJLAoRKGwi3IZu+CitHj7yzLpKL1Xhvaif+I6DPLMeX8NiM7ZuyJuWHSGSYTl6HG xd+3BKaytxXiGbKVs9UNPq0D6C8Icb1hzpOu9IU1A5rfuDs5VslBda4OJ//EEMPvwF4n PE1zfcbejNENapduP0RRiqGixBOor3xavl27YwT+7ZvnmTiJGOAIUeDHN5LDi36U8WMB GD9p6AqIG26B3paOn1TsHGwe09Yro5rXtxCVMOYheE1tdAMX30wmWrm9VsrpJ5lHERNz UFDg== X-Forwarded-Encrypted: i=1; AJvYcCW5acCYZCtRaqHuP9aZninZtk5snW5vSxpAowHCt3tpjYVXrW0AwcMZoQkL0DE9S+P/umhsQK2MJYtELqk=@vger.kernel.org X-Gm-Message-State: AOJu0YxotWJ5X2/M7luuAlQQB0dg+6m67OU0QWr+QV984MKkfFA9Es2E XdR/MQDJa9kKWgmtPp5KNjiOsvhRvszmrDx3LnSD1KSjULASpSgULzed X-Gm-Gg: AZuq6aI0FfK/tiUH7OU+/R1PJvVuvcoTBqITXDK6N/Y9cPvfh8FwLh+PiV0sKN+X8mF hTUF0RUziRh5alriF8IMNqvjpbon3AtB4i2Dw0lInkHYY+VRfwtbTokSzCgo0QOsCLF0rlznppb npWJcpI4/NzJrMmTt1pQFbin3Cgx+1gyd0JVekxUA48aCsVYvP7V59veI8iBk8hxdYZUrs+/Ndj ljVGTJGxeJ7DZ7FSz+kLOgwBmQKj+Dr/ODOal8tR3J8tNlw3YspnFjg+MpOKqdu4cMJgCXfTMaI pc05FsGZqRP5HzXRNpg/BrUoQxkOctZOTY5arHBLbOCjfbfmO+rKCQ0ck/Z9qIAk6mVUmJmyJrB QlI5IsbDTbr+KKTxRuLKRbI995QW8+6vBgsiuMExHTFJ4VFBWHy48+mwFRZg8ivjtLATV+h3J+M Qjjein+5ReiwWzWkd8KGyxAsAR13J2+R8LOGxP4OVaB5TJJcLIZhUGKhc+MPWemFA= X-Received: by 2002:adf:e806:0:b0:436:2fdf:b599 with SMTP id ffacd0b85a97d-4362fdfb8ffmr3540864f8f.21.1770459952919; Sat, 07 Feb 2026 02:25:52 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-436296b2d43sm12009599f8f.8.2026.02.07.02.25.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 07 Feb 2026 02:25:52 -0800 (PST) Date: Sat, 7 Feb 2026 10:25:51 +0000 From: David Laight To: Andrew Morton Cc: Peter Anvin , Andy Shevchenko , Arnd Bergmann , Christoph Hellwig , "Jason A . Donenfeld" , Herve Codina , Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: [PATCH next] minmax.h: Use auto for variables in __minmax_array() Message-ID: <20260207102551.74a42680@pumpkin> In-Reply-To: <20260206144135.89b1edb4f25fed21b7a1ccc9@linux-foundation.org> References: <20260206222554.676171-1-david.laight.linux@gmail.com> <20260206144135.89b1edb4f25fed21b7a1ccc9@linux-foundation.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 6 Feb 2026 14:41:35 -0800 Andrew Morton wrote: > On Fri, 6 Feb 2026 22:25:54 +0000 david.laight.linux@gmail.com wrote: > > > From: David Laight > > > > 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