[Bug libgcc/106949] Memory leak using VLA with -fsplit-stack

[iam at datacompboy dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106949

--- Comment #2 from Anton Fedorov <iam at datacompboy dot ru> ---
Created attachment 53654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53654&action=edit
potential fix

I checked with the HEAD (43faf3e5445b571731e52faa1be085ecd0a09323) and the
issue is still there.

While it's kind of trivial to move the leak from "leak" to "not freed by the
end of the program" with proposed patch to create an empty segment, it doesn't
seems to fix the problem with the approach that there is no way to mark
malloc()'ed alloca()'s in case we are on the main stack segment.

But the problem extends beyond the allocation on the main segment -- no matter
when we enter the some large function that keeps calling the subfunction with
VLA/alloca, the memory will keep growing without collection.

For example, if we'll call leak function in a loop (imagine we run even
processing loop, network processing loop etc etc that calls some handler that
have alloca/VLA), the memory will grow without any way to free it.

```
static int leak(int s) {
  volatile int n[5000+s];

  for (int i = 0; i < s; i++) {
    n[i] = 0;
  }
  return -1;
}
int main() {
  int a = leak(1); a += a;
  for(int i = 0; i < 10000; ++i)
    a += leak(i+1);
  return 0;
}
```

I see the option to generate code to explicitly move N (number of calls to
__morestack_allocate_stack_space in the function) first dynamic_allocation
elements to free_dynamic_allocation list before execution return -- at cost of
extra check & jmp for case when stack is sufficient.

Given that -fsplit-stack accepts extra cost for stack guarantees -- this extra
cost for avoiding memory leak should be fine?