On Mon, Nov 10, 2025 at 07:58:58PM +0800, Gustavo A. R. Silva wrote: > -Wflex-array-member-not-at-end was introduced in GCC-14, and we are > getting ready to enable it, globally. > > Use the new TRAILING_OVERLAP() helper to fix the following warning: > > drivers/md/bcache/bset.h:330:27: warning: structure containing a flexible > array member is not at the end of another structure > [-Wflex-array-member-not-at-end] > > This helper creates a union between a flexible-array member (FAM) and a > set of MEMBERS that would otherwise follow it. > > This overlays the trailing MEMBER struct btree_iter_set stack_data[MAX_BSETS]; > onto the FAM struct btree_iter::data[], while keeping the FAM and the start > of MEMBER aligned. > > The static_assert() ensures this alignment remains, and it's > intentionally placed inmediately after the corresponding structures --no > blank line in between. > > Signed-off-by: Gustavo A. R. Silva <[email protected]> > --- > drivers/md/bcache/bset.h | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/md/bcache/bset.h b/drivers/md/bcache/bset.h > index 011f6062c4c0..6ee2c6a506a2 100644 > --- a/drivers/md/bcache/bset.h > +++ b/drivers/md/bcache/bset.h > @@ -327,9 +327,13 @@ struct btree_iter { > /* Fixed-size btree_iter that can be allocated on the stack */ > > struct btree_iter_stack { > - struct btree_iter iter; > - struct btree_iter_set stack_data[MAX_BSETS]; > + /* Must be last as it ends in a flexible-array member. */ > + TRAILING_OVERLAP(struct btree_iter, iter, data, > + struct btree_iter_set stack_data[MAX_BSETS]; > + ); > }; > +static_assert(offsetof(struct btree_iter_stack, iter.data) == > + offsetof(struct btree_iter_stack, stack_data)); >
I have to say this is ugly. Not the patch, but the gcc 14 warning option of such coding style. Look at TRAILING_OVERLAP() usage here, this is not C, this is something to fix a gcc bug which cannot handle FAM properly. Gustavo, this complain is not to you, just I feel a bit sad how GCC makes the code comes to such an ugly way, and it makes things much complicated. For anyone doesn't have deep understanding of TRAILING_OVERLAP(), I highly suspect whether he or she can understand what happens here. Andrew and Gustavo, is this a mandatary to fix FAM in such way? If yes I take the patch and keep my own opinion. If not, I'd like to see gcc fixes its bug, for the this code I don't see the author does things wrong. Coly Li
