On Mon, Mar 27, 2023 at 12:55:04PM +0300, Andy Shevchenko wrote:
> +Cc clang (for the ideas you might have, while the issue seems related to GCC[?] )
>
> On Sun, Mar 26, 2023 at 08:01:23PM -0400, William Breathitt Gray wrote:
> > On Fri, Mar 24, 2023 at 11:35:02AM -0400, William Breathitt Gray wrote:
> > > There are eight calls to quad8_control_register_update() in 104-quad-8:
> > >
> > > quad8_control_register_update(priv, priv->idr, id, DISABLE_INDEX_MODE, INDEX_MODE);
> > > quad8_control_register_update(priv, priv->cmr, id, mode_cfg, QUADRATURE_MODE);
> > > quad8_control_register_update(priv, priv->ior, event_node->channel, flg_pins, FLG_PINS);
> > > quad8_control_register_update(priv, priv->idr, channel_id, index_polarity, INDEX_POLARITY);
> > > quad8_control_register_update(priv, priv->idr, channel_id, synchronous_mode, INDEX_MODE);
> > > quad8_control_register_update(priv, priv->cmr, count->id, count_mode, COUNT_MODE);
> > > quad8_control_register_update(priv, priv->ior, count->id, enable, AB_GATE);
> > > quad8_control_register_update(priv, priv->ior, count->id, !preset_enable, LOAD_PIN);
> >
> > I attempted the cross-compiling using an x86-64 system and I was able to
> > recreate the build error. I tried to isolate the problem line by
> > commenting out quad8_control_register_update() calls and discover that
> > this appears to be an inline issue after all: if there are more than six
> > calls to quad8_control_register_update() are in the code, then the
> > '__bad_mask' build error occurs.
> >
> > The build error doesn't occur if I force the inline via __always_inline,
> > so I'll add that to quad8_control_register_update() to resolve this
> > issue and submit a v3 patchset later this week.
>
> Doe it mean it's a compiler error? Or is it a code error?
>
> I'm wondering if clang also fails here.
>
> --
> With Best Regards,
> Andy Shevchenko
Al, I think you were the one who introduced the field_multiplier()
implementation in commit 00b0c9b82663ac ("Add primitives for
manipulating bitfields both in host- and fixed-endian."). Is this build
error [0] expected in your opinion?
I see that the field specification must be a constant according to the
commit description, so does that mean a "const u8 field" parameter is
valid? Does the field_multiplier() implementation have an expectation
that the condition check will be evaluated by the compiler during the
build and bypass the __bad_mask() compile time error so that it doesn't
appear?
William Breathitt Gray
[0] https://lore.kernel.org/all/202303241128.WBKc4LIy-lkp@xxxxxxxxx/
Attachment:
signature.asc
Description: PGP signature
