Hi, I'm not sure I agree with your statement that nobody liked this proposal. I believe most of the feedback was positive on the functionality - with many people suggesting short term alternatives on how this can be (partially) solved with existing functionality (the macro approach). I think most people recognized the limitation of the macro approach.
Some people suggested expanding the proposal (e.g., support C++, generic functionality to modify diagnostic level (warning, error, info, none) for any warning.in a statement/block/function scope). I reviewed them and for practical reasons (significantly increased effort, complexity, risk) - I'm sticking with the "narrow" scope. I apologize if this was not clear from my summary. Specifically - the -Wvla-larger-than would fall into expanding the scope to generalize the functionality. In projects i'm working with, we use all the larger-than warnings - (as warnings) - as we always want to be alerted when allocation crosses a certain boundary- so that a small upgrade to #define that impact allocation will not go unnoticed. Yair On Fri, Feb 27, 2026 at 9:33 AM Jonathan Wakely <[email protected]> wrote: > > On Fri, 27 Feb 2026 at 14:01, Yair Lenga via Gcc <[email protected]> wrote: > > > > Hello GCC maintainers, > > > > I recently proposed an attribute to suppress -Wvla on a single declaration. > > Thank you to everyone who provided feedback. I would like to summarize the > > discussion and outline the next step. > > > > Macro-based solutions > > > > Several replies noted that the problem can be addressed today with a macro > > wrapping diagnostic pragmas, for example: > > > > #define ALLOW_VLA(decl) > > _Pragma("GCC diagnostic push") > > _Pragma("GCC diagnostic ignored "-Wvla"") > > decl > > _Pragma("GCC diagnostic pop") > > > > This approach is workable and is used in some code bases (including ours). > > However it has practical drawbacks: > > > > diagnostics originating from the macro expansion are less clear, > > > > tools such as static analyzers and refactoring tools may not interpret > > the construct well, > > > > portability requires conditional definitions per compiler, > > > > the annotation is not attached to the declaration in the AST. > > > > In contrast, existing attributes such as [[maybe_unused]] and > > [[fallthrough]] > > attach intent directly to the relevant construct and are consistently > > visible > > to both the compiler and external tooling. > > > > Generalized diagnostic-control attributes > > > > There was also a suggestion to generalize this into attributes controlling > > arbitrary diagnostics and/or larger scopes (blocks, functions), for example: > > > > [[gnu::diagnostic_ignored("-Wvla")]] { ... } > > > > While this is an interesting direction, it substantially increases scope > > (design of attribute semantics, interaction with existing diagnostic > > pragmas, > > lifetime rules, etc.). > > > > The motivation of the current proposal is narrower: for VLA specifically, > > the goal is to mark intentional and reviewed use at the point of > > declaration, > > rather than to provide a general warning-suppression mechanism. > > > > Usefulness and expected adoption > > > > A concern was raised that this may serve only limited use cases. > > > > My expectation is that projects enabling -Wvla (often as part of stricter > > safety profiles) occasionally need small, bounded VLAs where heap allocation > > or fixed limits are impractical. Today these are either hidden behind macros > > or require local pragma ranges. An attribute provides a clearer and more > > auditable expression of intent. > > I don't think you've addressed the -Wvla-larger-than=N option in this summary. > > > > > Next step > > > > Based on the feedback, I plan to proceed with a minimal implementation > > restricted to: > > > > attribute applicable to a single VLA declaration, > > > > effect equivalent to suppressing -Wvla for that declaration only, > > > > no change to pragma behavior or other diagnostics. > > > > I will send a patch to gcc-patches for review. > > > > If there are concerns with this narrowed scope or the proposed direction, > > please let me know. > > How is this a narrowed scope? Isn't it just your original proposal, > which nobody liked?
