Message ID | 52952170-f1a9-89a0-e307-f974ce2b7977@fu-berlin.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp935062wrn; Sat, 21 Jan 2023 16:31:12 -0800 (PST) X-Google-Smtp-Source: AMrXdXvBvbVic5meRuLP9H5HNxwzHML08XGqCHhOVbnysPFnK1RVMoN7O4OIXdTw50Gc9TeMlVju X-Received: by 2002:aa7:9250:0:b0:58d:917e:59d8 with SMTP id 16-20020aa79250000000b0058d917e59d8mr17445385pfp.7.1674347472667; Sat, 21 Jan 2023 16:31:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674347472; cv=none; d=google.com; s=arc-20160816; b=gYxtRCCUJ4k6X5g+DWyjjoObMG1+tnzuYH/hdn8Z/7bZbV71ZTG4SmDsNsH0WYta++ 4Jj3Dc6ysaXco4aTVV4SRQ1FJEAM6do0SH+ieEGZbKuOHqjaSm/v2z2yfVmi+gswjNba bxHSQbbSf9VwDN1ah36cdTtKjEUc8hng7F1Cfs0PYlxHZFaUttycfgtzhaw8TfV6uypH sX8FClOKVrXJyrEi3/PIfWb2bRSD3oPOsFPthfOt17rcKb+EJ9K1m4pyDpZuF84SM2Ho RFrsGgbXEYqY6NztkWUoN9VL+2ohvohlgrncxT2u10Fkkf3MtTVDrNkBKERPsOiuXYYt TcEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:subject:cc:from:to :user-agent:mime-version:date:message-id; bh=jd1eiYuMHcnHIdWx4Lp2uiLgKXX8dIcjh0/xD7Kbv20=; b=XxHL464YGpzL+RE03HfoOFDfAaHSTyGgHMRknDYni0gXV2HThNhZKS65Yih+ko7Nvj meJ0yngD3HBnfFiEsLPvkngbQye/ufY/F7Wiht1KJ9CNyW9XttOv6F+EbRmN4Md6uQHx aQA5SRPo47JqDk9Zs6AXx2evepqHuwAEIft/PbSzgcBZaqy7sd98H9pfCkIMhRCv8suy 5glrwijUyMjDe8cluLvOvNJC0a5OrD6OB2I3G6MRdXhswYLuWHthqGCfMij0eSm4vXch kmD5AgYEpYl6/Hqt7t4W2GWKRIjGBrYy4diHTkc9Shkuz3VE9cSYREO96h+OPnQf2EXB oh5Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e9-20020a056a001a8900b0058db2696e2asi19879309pfv.313.2023.01.21.16.31.00; Sat, 21 Jan 2023 16:31:12 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229680AbjAVAPX (ORCPT <rfc822;forouhar.linux@gmail.com> + 99 others); Sat, 21 Jan 2023 19:15:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229463AbjAVAPW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 21 Jan 2023 19:15:22 -0500 Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5960A17CE8; Sat, 21 Jan 2023 16:15:21 -0800 (PST) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.95) with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from <mkarcher@zedat.fu-berlin.de>) id 1pJO10-002AZK-CU; Sun, 22 Jan 2023 01:15:18 +0100 Received: from pd9f631ca.dip0.t-ipconnect.de ([217.246.49.202] helo=[192.168.144.87]) by inpost2.zedat.fu-berlin.de (Exim 4.95) with esmtpsa (TLS1.3) tls TLS_AES_128_GCM_SHA256 (envelope-from <Michael.Karcher@fu-berlin.de>) id 1pJO0z-002Kk0-Vw; Sun, 22 Jan 2023 01:15:18 +0100 Message-ID: <52952170-f1a9-89a0-e307-f974ce2b7977@fu-berlin.de> Date: Sun, 22 Jan 2023 01:15:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 To: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org, Segher Boessenkool <segher@kernel.crashing.org>, Rich Felker <dalias@libc.org>, Yoshinori Sato <ysato@users.sourceforge.jp>, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> From: "Michael.Karcher" <Michael.Karcher@fu-berlin.de> Cc: jakub@gcc.gnu.org Subject: [PATCH: 1/1] sh4: avoid spurious gcc warning Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Original-Sender: Michael.Karcher@fu-berlin.de X-Originating-IP: 217.246.49.202 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755680575534433002?= X-GMAIL-MSGID: =?utf-8?q?1755680575534433002?= |
Series |
[PATCH:,1/1] sh4: avoid spurious gcc warning
|
|
Commit Message
Michael.Karcher
Jan. 22, 2023, 12:15 a.m. UTC
Prevent sizeof-pointer-div warning in SH4 intc macros
Gcc warns about the pattern sizeof(void*)/sizeof(void), as it looks like
the abuse of a pattern to calculate the array size. This pattern appears
in the unevaluated part of the ternary operator in _INTC_ARRAY if the
parameter is NULL.
The replacement uses an alternate approach to return 0 in case of NULL
which does not generate the pattern sizeof(void*)/sizeof(void), but still
emits the warning if _INTC_ARRAY is called with a nonarray parameter.
This patch is required for successful compilation with -Werror enabled.
The idea to use _Generic for type distinction is taken from Comment #7
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 by Jakub Jelinek
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
---
prio_regs, sense_regs, ack_regs) \
Comments
Hi-- It's just sh: AFAICT. The patch fixes the build error for me on sh2, using gcc 12.1.0 from the kernel.org crosstool builds. On 1/21/23 16:15, Michael.Karcher wrote: > Prevent sizeof-pointer-div warning in SH4 intc macros > > Gcc warns about the pattern sizeof(void*)/sizeof(void), as it looks like > the abuse of a pattern to calculate the array size. This pattern appears > in the unevaluated part of the ternary operator in _INTC_ARRAY if the > parameter is NULL. > > The replacement uses an alternate approach to return 0 in case of NULL > which does not generate the pattern sizeof(void*)/sizeof(void), but still > emits the warning if _INTC_ARRAY is called with a nonarray parameter. > > This patch is required for successful compilation with -Werror enabled. > > The idea to use _Generic for type distinction is taken from Comment #7 > in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 by Jakub Jelinek > > Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> > --- > > diff --git a/include/linux/sh_intc.h b/include/linux/sh_intc.h > index c255273b0281..d7a7ffb60a34 100644 > --- a/include/linux/sh_intc.h > +++ b/include/linux/sh_intc.h > @@ -97,7 +97,7 @@ struct intc_hw_desc { > unsigned int nr_subgroups; > }; > > -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) > +#define _INTC_ARRAY(a) a, sizeof(a)/(_Generic((a), typeof(NULL): 0xFFFFFFFFU, default: sizeof(*a))) s/: / : / in 2 places. Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested How far back in gcc versions does this work? Thanks. > > #define INTC_HW_DESC(vectors, groups, mask_regs, \ > prio_regs, sense_regs, ack_regs) \ >
Am 22.01.2023 um 08:00 schrieb Randy Dunlap: >> -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) >> +#define _INTC_ARRAY(a) a, sizeof(a)/(_Generic((a), typeof(NULL): 0xFFFFFFFFU, default: sizeof(*a))) > s/: / : / in 2 places. > > Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Thanks for your confirmation! Are you sure about the space before the colon? The colon in this case terminates a case descriptor for the type-level switch construction using "_Generic". It says: "In case 'a' has the 'type of NULL', divide by 0xFFFFFFFFU, in all other cases, divide by the size of a single array element". It's not a colon of the ternary ?: operator, in which case I would agree with the space before it. If you confirm that you want a space before the colon in this case as well, I'm going to add it, though. > How far back in gcc versions does this work? I tested the support of _Generic on Compiler Explorer at godbolt.org. This construction is rejected by gcc 4.8, but accepted by gcc 4.9. Kind regards, Michael Karcher
Hi Michael! On 1/22/23 01:15, Michael.Karcher wrote: > Prevent sizeof-pointer-div warning in SH4 intc macros > > Gcc warns about the pattern sizeof(void*)/sizeof(void), as it looks like > the abuse of a pattern to calculate the array size. This pattern appears > in the unevaluated part of the ternary operator in _INTC_ARRAY if the > parameter is NULL. > > The replacement uses an alternate approach to return 0 in case of NULL > which does not generate the pattern sizeof(void*)/sizeof(void), but still > emits the warning if _INTC_ARRAY is called with a nonarray parameter. > > This patch is required for successful compilation with -Werror enabled. > > The idea to use _Generic for type distinction is taken from Comment #7 > in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 by Jakub Jelinek > > Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> > --- > > diff --git a/include/linux/sh_intc.h b/include/linux/sh_intc.h > index c255273b0281..d7a7ffb60a34 100644 > --- a/include/linux/sh_intc.h > +++ b/include/linux/sh_intc.h > @@ -97,7 +97,7 @@ struct intc_hw_desc { > unsigned int nr_subgroups; > }; > > -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) > +#define _INTC_ARRAY(a) a, sizeof(a)/(_Generic((a), typeof(NULL): 0xFFFFFFFFU, default: sizeof(*a))) > > #define INTC_HW_DESC(vectors, groups, mask_regs, \ > prio_regs, sense_regs, ack_regs) \ The title should probably be "arch/sh: avoid spurious gcc warning" since it's not a problem special to sh4 but affects the whole arch/sh sub-folder which covers all SuperH and J-Core targets. Can you rephrase the title accordingly? Adrian
On Sun, Jan 22, 2023 at 12:33:41PM +0100, Michael Karcher wrote: > Am 22.01.2023 um 08:00 schrieb Randy Dunlap: > > > -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) > > > +#define _INTC_ARRAY(a) a, sizeof(a)/(_Generic((a), typeof(NULL): 0xFFFFFFFFU, default: sizeof(*a))) > > s/: / : / in 2 places. > > > > Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested > > Thanks for your confirmation! Are you sure about the space before the colon? No, it should be without those, see various other _Generic uses in include/linux/ All those are formatted on one line for each case, so for the above macro it would be #define _INTC_ARRAY(a) (a), sizeof(a)/(_Generic((a), \ typeof(NULL): -1, \ default: sizeof(*(a))) or so. Anyway, two comments: 1) I'd use -1 as that would be after promotion to size_t the largest size_t unlike 0xFFFFFFFFU; of course, as for the void * case a can't be an array, any value > sizeof(void*) will do 2) if *a and a is fine (i.e. argument of the macro has to be really simple or wrapped in ()s, then perhaps (a) as first operand to _Generic isn't needed either, or use (a) in the two spots (sizeof(a) is of course fine) and *(a) > The colon in this case terminates a case descriptor for the type-level > switch construction using "_Generic". It says: "In case 'a' has the 'type of > NULL', divide by 0xFFFFFFFFU, in all other cases, divide by the size of a > single array element". It's not a colon of the ternary ?: operator, in which > case I would agree with the space before it. > > If you confirm that you want a space before the colon in this case as well, > I'm going to add it, though. > > > How far back in gcc versions does this work? > > I tested the support of _Generic on Compiler Explorer at godbolt.org. This > construction is rejected by gcc 4.8, but accepted by gcc 4.9. Yeah, introduced in gcc 4.9, as I think kernel minimum version is 5.1, that is fine. And various headers already use _Generic. Jakub
On 1/22/23 04:42, Jakub Jelinek wrote: > On Sun, Jan 22, 2023 at 12:33:41PM +0100, Michael Karcher wrote: >> Am 22.01.2023 um 08:00 schrieb Randy Dunlap: >>>> -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) >>>> +#define _INTC_ARRAY(a) a, sizeof(a)/(_Generic((a), typeof(NULL): 0xFFFFFFFFU, default: sizeof(*a))) >>> s/: / : / in 2 places. >>> >>> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested >> >> Thanks for your confirmation! Are you sure about the space before the colon? Nope, my bad. Thanks, Jakub. > No, it should be without those, see various other _Generic uses in > include/linux/ > All those are formatted on one line for each case, so for the above macro it > would be > #define _INTC_ARRAY(a) (a), sizeof(a)/(_Generic((a), \ > typeof(NULL): -1, \ > default: sizeof(*(a))) > or so. > Anyway, two comments: > 1) I'd use -1 as that would be after promotion to size_t the largest size_t > unlike 0xFFFFFFFFU; of course, as for the void * case a can't be an array, > any value > sizeof(void*) will do > 2) if *a and a is fine (i.e. argument of the macro has to be really simple or > wrapped in ()s, then perhaps (a) as first operand to _Generic isn't needed > either, or use (a) in the two spots (sizeof(a) is of course fine) and > *(a) > >> The colon in this case terminates a case descriptor for the type-level >> switch construction using "_Generic". It says: "In case 'a' has the 'type of >> NULL', divide by 0xFFFFFFFFU, in all other cases, divide by the size of a >> single array element". It's not a colon of the ternary ?: operator, in which >> case I would agree with the space before it. >> >> If you confirm that you want a space before the colon in this case as well, >> I'm going to add it, though. >> >>> How far back in gcc versions does this work? >> >> I tested the support of _Generic on Compiler Explorer at godbolt.org. This >> construction is rejected by gcc 4.8, but accepted by gcc 4.9. > > Yeah, introduced in gcc 4.9, as I think kernel minimum version is 5.1, that is fine. > And various headers already use _Generic. and thanks for that info also.
Hi Jakub, On Sun, Jan 22, 2023 at 1:47 PM Jakub Jelinek <jakub@redhat.com> wrote: > On Sun, Jan 22, 2023 at 12:33:41PM +0100, Michael Karcher wrote: > > Am 22.01.2023 um 08:00 schrieb Randy Dunlap: > > > > -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) > > > > +#define _INTC_ARRAY(a) a, sizeof(a)/(_Generic((a), typeof(NULL): 0xFFFFFFFFU, default: sizeof(*a))) > > > s/: / : / in 2 places. > > > > > > Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested > > > > Thanks for your confirmation! Are you sure about the space before the colon? > > No, it should be without those, see various other _Generic uses in > include/linux/ > All those are formatted on one line for each case, so for the above macro it > would be > #define _INTC_ARRAY(a) (a), sizeof(a)/(_Generic((a), \ > typeof(NULL): -1, \ > default: sizeof(*(a))) > or so. > Anyway, two comments: > 1) I'd use -1 as that would be after promotion to size_t the largest size_t > unlike 0xFFFFFFFFU; of course, as for the void * case a can't be an array, > any value > sizeof(void*) will do Or SIZE_MAX. include/linux/limits.h:#define SIZE_MAX (~(size_t)0) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, Jan 23, 2023 at 04:06:27PM +0000, David Laight wrote: > From: Michael.Karcher > > Sent: 22 January 2023 00:15 > > > > Prevent sizeof-pointer-div warning in SH4 intc macros > > > > Gcc warns about the pattern sizeof(void*)/sizeof(void), as it looks like > > the abuse of a pattern to calculate the array size. This pattern appears > > in the unevaluated part of the ternary operator in _INTC_ARRAY if the > > parameter is NULL. > > > > The replacement uses an alternate approach to return 0 in case of NULL > > which does not generate the pattern sizeof(void*)/sizeof(void), but still > > emits the warning if _INTC_ARRAY is called with a nonarray parameter. > > > > This patch is required for successful compilation with -Werror enabled. > > > > The idea to use _Generic for type distinction is taken from Comment #7 > > in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483 by Jakub Jelinek > > > > Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> > > --- > > > > diff --git a/include/linux/sh_intc.h b/include/linux/sh_intc.h > > index c255273b0281..d7a7ffb60a34 100644 > > --- a/include/linux/sh_intc.h > > +++ b/include/linux/sh_intc.h > > @@ -97,7 +97,7 @@ struct intc_hw_desc { > > unsigned int nr_subgroups; > > }; > > > > -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) > > FWIW it is (currently) enough to add 0 to the top or bottom > of the division. If you don't want the warning at all, sure. But if you want the compiler to warn if you use the macro on a (non-void *) pointer rather than array, what has been posted is needed. Jakub
Am 23.01.2023 um 17:11 schrieb Jakub Jelinek: > On Mon, Jan 23, 2023 at 04:06:27PM +0000, David Laight wrote: >> From: Michael.Karcher >>> -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) >> FWIW it is (currently) enough to add 0 to the top or bottom >> of the division. > If you don't want the warning at all, sure. But if you want the compiler > to warn if you use the macro on a (non-void *) pointer rather than array, > what has been posted is needed. Exactly. I actually had sizeof(a)/(sizeof(*a) + 0) at first, but a test showed that it would silently generate invalid code on struct intc_mask_reg singleton = {...}; _INTC_ARRAY(&singleton) If it would expand to "&singleton, 1", it would be fine, but it will expand to "&singleton, 0", as sizeof(intc_mask_reg*) is smaller than sizeof(intc_mask_reg). The version I posted generates the intended warning (upgraded to an error with -Werror) in that case. The old version also generated the intended warning in this case, and not generating a warning here is a regression I didn't want to be responsible for. Kind regards, Michael Karcher
diff --git a/include/linux/sh_intc.h b/include/linux/sh_intc.h index c255273b0281..d7a7ffb60a34 100644 --- a/include/linux/sh_intc.h +++ b/include/linux/sh_intc.h @@ -97,7 +97,7 @@ struct intc_hw_desc { unsigned int nr_subgroups; }; -#define _INTC_ARRAY(a) a, __same_type(a, NULL) ? 0 : sizeof(a)/sizeof(*a) +#define _INTC_ARRAY(a) a, sizeof(a)/(_Generic((a), typeof(NULL): 0xFFFFFFFFU, default: sizeof(*a))) #define INTC_HW_DESC(vectors, groups, mask_regs, \