[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f5eb6cb1-c1f5-5a13-2b22-374adc70acec@mkarcher.dialup.fu-berlin.de>
Date:   Mon, 23 Jan 2023 19:00:39 +0100
From:   Michael Karcher <kernel@...rcher.dialup.fu-berlin.de>
To:     Jakub Jelinek <jakub@...hat.com>,
        David Laight <David.Laight@...lab.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-sh@...r.kernel.org" <linux-sh@...r.kernel.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Rich Felker <dalias@...c.org>,
        Yoshinori Sato <ysato@...rs.osdn.me>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        "jakub@....gnu.org" <jakub@....gnu.org>
Subject: Re: [PATCH: 1/1] sh4: avoid spurious gcc warning
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
Powered by blists - more mailing lists