From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB82BC32793 for ; Wed, 18 Jan 2023 20:35:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230033AbjARUfE (ORCPT ); Wed, 18 Jan 2023 15:35:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229770AbjARUem (ORCPT ); Wed, 18 Jan 2023 15:34:42 -0500 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B79E85EFBF for ; Wed, 18 Jan 2023 12:33:22 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D19EA5C00C7; Wed, 18 Jan 2023 15:33:06 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Wed, 18 Jan 2023 15:33:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm2; t=1674073986; x=1674160386; bh=iJGSvZEAeF qQdWIKfDucEMI+v1mVjLVCzF+2CZKpJeQ=; b=n1grkTLPGuXJ92lFVLzwtmGUiD AaCT+aLgke39a0nSg6oN+pRuUvZtCv2K7n/AY/ThN+RikRcol73uQck0FG8A1rVc HVewAghVHGuN9XYXNLopg1a6JhodqWn4870pGvBZUAMMPi8TIQ3DD9gI6tyOg2L5 b2im4ruMbFHq6XsnWVfxbpg4oqqej4tbF8n87acuuQsXsvqHBqaVb5Bs6GN71/2Q qM+bymsI8dh5dV0236/bLT2dWnWNSzIGNdYpS8zOZQtatz5G5nkjA2KwbdmKZNq+ t65qCw/f6MSz3cBjPbTnCsp8VI/JGhNI8NOZVMoFZLXEhhBvCQ5h5ZxiaJQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1674073986; x=1674160386; bh=iJGSvZEAeFqQdWIKfDucEMI+v1mV jLVCzF+2CZKpJeQ=; b=llRm8ihNth8j2k6V4srAwXuCkCSdbgrYZzX5/8CnZwKb zCoKqe5Pw8ISnzPkwEuob7YvppusejPLppS4TuzOV4b11nI87QSkO2+7iPFJBguF gIqUlZto9plzXz8eHV99pMFYU4Jyc4dnh96q/dgyj0/w+GtQZJGgDmrvctv0Kd1W DaySHfGXWF+qoz58CLfWrso9Py3NYdGqBfMLzNHkFeCfFD6lKWz9vOfwP99w+Qj+ Uhr7J5uMiQjQOeOs824C1uN7BO7rsHffWUGI3o8bxRtrI9huEyL7AkoKqecRH2B3 nT5qfQjeJc7ECSzCvRZGa2dOr1Gtr7S2xm6F5FyCAw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtkedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdet rhhnugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrg htthgvrhhnpeeigfeiieeiheejjeeiudekleevvddvffetieehteeikeeigeeiffdttdef tdeggfenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegrrhhnugesrghrnhgusgdruggv X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3A84CB60086; Wed, 18 Jan 2023 15:33:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-1187-g678636ba0d-fm-20230113.001-g678636ba Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20230117164041.1207412-1-arnd@kernel.org> <99ea6e86d2594b40a6de96cc821c447b@AcuMS.aculab.com> Date: Wed, 18 Jan 2023 21:32:45 +0100 From: "Arnd Bergmann" To: "Tejun Heo" Cc: "Arnd Bergmann" , "Lai Jiangshan" , "Richard Clark" , =?UTF-8?Q?Jonathan_Neusch=C3=A4fer?= , "Andrey Grodzovsky" , "Tetsuo Handa" , "linux-kernel@vger.kernel.org," , "David Laight" Subject: Re: [PATCH] workqueue: fix enum type for gcc-13 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 18, 2023, at 17:38, Tejun Heo wrote: >> From: Arnd Bergmann >> > Sent: 17 January 2023 16:41 >> > >> > In gcc-13, the WORK_STRUCT_WQ_DATA_MASK constant is a signed 64-bit >> > type on 32-bit architectures because the enum definition has both >> > negative numbers and numbers above LONG_MAX in it: >> > >> ... >> > /* convenience constants */ >> > WORK_STRUCT_FLAG_MASK = (1UL << WORK_STRUCT_FLAG_BITS) - 1, >> > - WORK_STRUCT_WQ_DATA_MASK = ~WORK_STRUCT_FLAG_MASK, >> > + WORK_STRUCT_WQ_DATA_MASK = (unsigned long)~WORK_STRUCT_FLAG_MASK, >> > WORK_STRUCT_NO_POOL = (unsigned long)WORK_OFFQ_POOL_NONE << WORK_OFFQ_POOL_SHIFT, > > I have a hard time understanding why gcc would change its behavior so that > there's no way to compile the same code in a consistent manner across two > adjacent compiler versions. The new behavior is fine but it makes no sense > to introduce it like this. If at all possible, marking gcc13 broken sounds > about right to me. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 has some more information on the change. In short, the old behavior was a gcc extension that was somewhat surprising and not well documented, while the new behavior is consistent with C23 and C++ as well as easier to understand: Any constant that is defined as part of an enum now has the same type as the enum itself, even if it fits within a shorter type. In a definition like enum e { A = -1, B = -1u, }; the enum type has to be compatible with 'long long' because anything shorter would not fit both -1 and -1u (UINT_MAX). A and B were both signed types to match the signedness of the enum type, but A was actually a 32-bit integer since that is sufficient, while B was also a 64-bit type since it exceeds INT_MAX. Now they are both the same type. I don't think there is a chance they will revert to the old behavior, though we could try asking for an command line flag to warn about cases where this changes code generation. Arnd