Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Tejun Heo <htejun@gmail.com>
Date:   Wed, 18 Jan 2023 06:38:32 -1000
From:   Tejun Heo <tj@kernel.org>
To:     David Laight <David.Laight@aculab.com>
Cc:     'Arnd Bergmann' <arnd@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        Richard Clark <richard.xnu.clark@gmail.com>,
        Jonathan =?iso-8859-1?Q?Neusch=E4fer?= <j.neuschaefer@gmx.net>,
        Andrey Grodzovsky <andrey.grodzovsky@amd.com>,
        Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] workqueue: fix enum type for gcc-13
Message-ID: <Y8ggiF+7k0rViXcY@slm.duckdns.org>
References: <20230117164041.1207412-1-arnd@kernel.org>
 <99ea6e86d2594b40a6de96cc821c447b@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <99ea6e86d2594b40a6de96cc821c447b@AcuMS.aculab.com>
Precedence: bulk

Hello,

On Wed, Jan 18, 2023 at 09:31:18AM +0000, David Laight 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,
> 
> How can that make any difference?
> You aren't changing the value or type (which makes no difference)
> of WORK_STRUCT_WQ_DATA_MASK.
> Indeed you require it to have the high bit set.
> 
> So if the enum contains a -1 somewhere gcc-13 will promote
> everything to s64.
> 
> Either declare gcc-13 as 'BROKEN' or change the:

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.

Thanks.

-- 
tejun