[<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