Re: [PATCH][next] bcache: Avoid -Wflex-array-member-not-at-end warning

[Coly Li]

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 <gustavoars@xxxxxxxxxx>
> ---
>  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