Hi Yair,
Am Freitag, dem 27.02.2026 um 13:39 -0500 schrieb Yair Lenga:
> Hi Martin,
>
> What criteria do we use in our team to allow/disallow.
>
> The main advantage of using VLA (over heap memory) is performance. So
> that questions that we ask during the view:
> 1. Is the function in "hot path" - executed repeatedly
> 2. What is the maximum memory that will be needed
> 3. In tight-loops - memory locality can be a factor
>
> For example: this will get approved:
> double foo_slices(int n, double *a)
> {
> double tmp[n] ; // need temporary array
> ... Use tmp
> return ... ;
> }
>
> int bar(...)
> {
> for (int i=0 ; i<nnn ; i++) foo_slices(v_len[i], v_data[ii]) ;
> }
>
> In the above example - calling malloc in foo_slices can slow the
> calculation, vs using VLA. As I mentioned, we found the performance
> gain coming from both the speed of the allocation, and from the fact
> that memory is usually allocated in L1/L2, whereas with malloc, you
> may get L3.
Thanks! But what about the negative cases, where would a VLA
be problematic and why?
I am wondering whether we can have warning that makes the manual
review unnecessary in the first place.
>
> Regarding the "code always produce warning"
>
> The -Wvla-larger than will NOT complain if MAX_POINTS was 25000
> (initial value), Will complain when header.h is changes to: #define
> MAX_POINTS 250000
Yes, you are right. I was confusing this with a scenario where the
compiler can not see the value, but still warns because the type
is signed.
void foo(int n)
{
if (n > 100) return;
char buf[n];
foo(n);
}
This is something I find to be a usability issue.
>
> Keeping the -Wvla-larger-than will allow give us an error if an
> "approved" usage of VLA will cross the accepted boundary. The warning
> on vla-larger-than will only get trigger if the array get "too much"
> bigger.
>
> As a side note - practical experience - The -Wvla-larger require
> compiling in O2 (O3 if using old GCC) - so it's much more "expensive"
> build. We use it for CI build - developer are using the faster "-Og"
> mode for regular development.
>
> Hope it make sense.
It does!
Martin
>
> Yair
>
> On Fri, Feb 27, 2026 at 12:51 PM Martin Uecker <[email protected]> wrote:
> >
> > Am Freitag, dem 27.02.2026 um 12:42 -0500 schrieb Yair Lenga via Gcc:
> > > Greetings!
> > >
> > > I'm happy to see discussion (including opposing/disagreeing opinions
> > > !) on my proposal.
> > >
> > > Wanted to cover one of the side-item in separate email - specifically
> > > keeping -Wvla-larger-than not impacted by the proposed [[gnu::vla]]
> > >
> > > In my projects, we use -Wvla and -Wvla-larger-than=512000 (~1MB, given
> > > each of our threads is configured for 5MB thread. This is the same
> > > setting we for frame-larger-than.
> > >
> > > Common scenario we have is:
> > >
> > > // In header.h
> > > #define MAX_POINTS 25000
> > >
> > > // In code
> > > int foo(void)
> > > {
> > > int n = MAX_POINTS ;
> > > ALLOW_VLA(int v[n+1] ) ; // ALLOW_VLA uses Pragma to ignore -Wvla
> > > }
> > >
> > > The "ALLOW_VLA" indicate that the usage was reviewed - and approved.
> >
> > Out of curiosity, what would are the criteria for this being allowed
> > or not? Or in other words, what is the actual use case you are
> > trying to address?
> >
> > BTW: this code would always cause a warning with -Wvla-larger-than=, so
> > I assume it actually looks a bit different.
> >
> > Martin
> >
> >
> > > Common issue that we have is that the header.h is modified -> #define
> > > MAX_POINTS 250000. The compiler does not warn on the VLA use - because
> > > we tagged it safe. Keeping -Wvla-larger-than=500KB allow us to be
> > > notified when of places where VLA usage is valid, but exceeds the
> > > threshold.
> > >
> > > Hope this use case is clean - and explain why I believe
> > > -Wvla-larger-than should NOT be impacted with the proposed [[gnu::lva]
> > >
> > > Regards,
> > > Yair
