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 <[email protected]>
---
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) \
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 <[email protected]>
> ---
>
> 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 <[email protected]> # 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) \
>
--
~Randy
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 <[email protected]> # 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 <[email protected]>
> ---
>
> 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
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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 <[email protected]> # 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 <[email protected]> # 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.
--
~Randy
Hi Jakub,
On Sun, Jan 22, 2023 at 1:47 PM Jakub Jelinek <[email protected]> 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 <[email protected]> # 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 -- [email protected]
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 <[email protected]>
> > ---
> >
> > 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