https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69759
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|__builtin_alloca |__builtin_alloca and
|undocumented |__builtin_alloca_with_align
| |undocumented
--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
The referenced man page doesn't describe __builtin_alloca() but rather the
alloca() function that need not be implemented in terms of the GCC built-in but
rather in terms of one provided by some other compiler.
The example I gave was meant to illustrate one of the questions about GCC's
__builtin_alloca()(*). I'm not concerned with the portability of the code in
it. What I am interested in is the general properties of GCC's
__builtin_alloca() that aren't discussed on the man page or that may differ
from it (even if they differ from one processor to another).
As an aside, if __builtin_alloca() was used in an unsafe (and perhaps even
unportable way), I would expect GCC to issue a warning. These too are aspects
that would be helpful to document.
That being said, since r179655, for some constructs (such as VLAs), GCC emits
calls to __builtin_alloca_with_align(). This intrinsic has some interesting
properties that make it quite different from __builtin_alloca() (for example,
when the alignment argument isn't valid it fails by returning null). It is
also undocumented.
Both intrinsics are being relied on by users who are experiencing problems with
them and who are dealing with them by trial and error. See for example
https://bugzilla.mozilla.org/show_bug.cgi?id=1111355. Documenting them should
help users avoid some of their pitfalls.
[*] In further testing it looks like __builtin_alloca() doesn't release the
allocated memory until the function returns in the majority of cases so the
issues I'm seeing might be simply be a matter of pushing the function in ways
it isn't meant to be used. Again, documenting it in the GCC manual would help.
