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 3BB9DC4332F for ; Tue, 13 Dec 2022 11:16:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235311AbiLMLQc (ORCPT ); Tue, 13 Dec 2022 06:16:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235404AbiLMLPn (ORCPT ); Tue, 13 Dec 2022 06:15:43 -0500 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0CD1E4C; Tue, 13 Dec 2022 03:15:07 -0800 (PST) Received: by mail-ej1-f49.google.com with SMTP id u19so17155940ejm.8; Tue, 13 Dec 2022 03:15:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JxAbmC5fTjrJjV2pr7W0uw74csIsAjG9pytfI1WxJUI=; b=f4Bzn5C1xckKlqT5014puwng2kD1E2/F4R2LPJBkKi5fyiSKUCgk3qlhN0w+M3YRw8 R2qBtROLfXXYXfW/CaOW8tVaZ1IvxgzIef448d2VEy0/bGr2SQGvZWc/WQsjMnWl9Uih JPiKxX4UEbtTTfF7PAJn4FL3owWaEEEnmcj1n6eWrAQljH7IKZcvkotFF87yqEZF0Dg1 OJUGHjbABmzWtQfB3GBoTcEZqVvHsSZljsvhEtoesWzE4jK+j6gFNTsiJnXEEbFmjiHJ MPj+z8Bo8R+0ytTp83MU+N2xI+5BmbitlSmrYttAsSjDoivADrQb3nOKIYhaJbR16tHv d/iQ== X-Gm-Message-State: ANoB5pks9Wu9jfXco/7mfwkUb4dVht1zFSE9JlNwzB7aR0z/zoGb256N eDXvMfqqayvL+vu8tI2nYOk= X-Google-Smtp-Source: AA0mqf7k1PUD5wczDK8PXN/VI6k3wtfoATIqdvkLuEay8VuzZbEuikeolbb22HXRTTkIcT+gQkSg8w== X-Received: by 2002:a17:907:d609:b0:7c1:4fea:cf2 with SMTP id wd9-20020a170907d60900b007c14fea0cf2mr11156996ejc.0.1670930106256; Tue, 13 Dec 2022 03:15:06 -0800 (PST) Received: from ?IPV6:2a0b:e7c0:0:107::aaaa:49? ([2a0b:e7c0:0:107::aaaa:49]) by smtp.gmail.com with ESMTPSA id bq19-20020a170906d0d300b007bf5250b515sm4414853ejb.29.2022.12.13.03.15.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Dec 2022 03:15:05 -0800 (PST) Message-ID: <9d2ead31-efab-cf49-08d4-1e613382d89f@kernel.org> Date: Tue, 13 Dec 2022 12:15:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints To: David Laight , 'Tejun Heo' Cc: Christoph Hellwig , "linux-kernel@vger.kernel.org" , Martin Liska , Josef Bacik , Jens Axboe , "cgroups@vger.kernel.org" , "linux-block@vger.kernel.org" References: <20221031114520.10518-1-jirislaby@kernel.org> <2b975ee3117e45aaa7882203cf9a4db8@AcuMS.aculab.com> <320c939e-a3f0-1b1e-77e4-f3ecca00465d@kernel.org> Content-Language: en-US From: Jiri Slaby In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 13. 12. 22, 9:30, David Laight wrote: > From: Tejun Heo On Behalf Of 'Tejun Heo' >> Sent: 12 December 2022 21:47 >> To: Jiri Slaby >> Cc: David Laight ; Christoph Hellwig ; linux- >> kernel@vger.kernel.org; Martin Liska ; Josef Bacik ; Jens Axboe >> ; cgroups@vger.kernel.org; linux-block@vger.kernel.org >> Subject: Re: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints >> >> On Mon, Dec 12, 2022 at 01:14:31PM +0100, Jiri Slaby wrote: >>>> If so, my suggestion is just sticking with the old behavior until we switch >>>> to --std=g2x and then make one time adjustment at that point. >>> >>> So is the enum split OK under these circumstances? >> >> Oh man, it's kinda crazy that the compiler is changing in a way that the >> same piece of code can't be compiled the same way across two adjoining >> versions of the same compiler. But, yeah, if that's what gcc is gonna do and >> splitting enums is the only way to be okay across the compiler versions, >> there isn't any other choice we can make. > > It is also a silent code-breaker. > Compile this for 32bit x86: > > enum { a = 1, b = ~0ull}; But having ull in an enum is undefined anyway. C99 allows only int constants. gnuC supports ulong expressions (IIRC). > extern int foo(int, ...); > int f(void) > { > return foo(0, a, 2); > } > > gcc13 pushes an extra zero onto the stack between the 1 and 2. So this is sort of "expected". thanks, -- js suse labs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jiri Slaby Subject: Re: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints Date: Tue, 13 Dec 2022 12:15:03 +0100 Message-ID: <9d2ead31-efab-cf49-08d4-1e613382d89f@kernel.org> References: <20221031114520.10518-1-jirislaby@kernel.org> <2b975ee3117e45aaa7882203cf9a4db8@AcuMS.aculab.com> <320c939e-a3f0-1b1e-77e4-f3ecca00465d@kernel.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: David Laight , 'Tejun Heo' Cc: Christoph Hellwig , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Martin Liska , Josef Bacik , Jens Axboe , "cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" On 13. 12. 22, 9:30, David Laight wrote: > From: Tejun Heo On Behalf Of 'Tejun Heo' >> Sent: 12 December 2022 21:47 >> To: Jiri Slaby >> Cc: David Laight ; Christoph Hellwig ; linux- >> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Martin Liska ; Josef Bacik ; Jens Axboe >> ; cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org >> Subject: Re: [PATCH] block/blk-iocost (gcc13): cast enum members to int in prints >> >> On Mon, Dec 12, 2022 at 01:14:31PM +0100, Jiri Slaby wrote: >>>> If so, my suggestion is just sticking with the old behavior until we switch >>>> to --std=g2x and then make one time adjustment at that point. >>> >>> So is the enum split OK under these circumstances? >> >> Oh man, it's kinda crazy that the compiler is changing in a way that the >> same piece of code can't be compiled the same way across two adjoining >> versions of the same compiler. But, yeah, if that's what gcc is gonna do and >> splitting enums is the only way to be okay across the compiler versions, >> there isn't any other choice we can make. > > It is also a silent code-breaker. > Compile this for 32bit x86: > > enum { a = 1, b = ~0ull}; But having ull in an enum is undefined anyway. C99 allows only int constants. gnuC supports ulong expressions (IIRC). > extern int foo(int, ...); > int f(void) > { > return foo(0, a, 2); > } > > gcc13 pushes an extra zero onto the stack between the 1 and 2. So this is sort of "expected". thanks, -- js suse labs