https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69759
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
So it is. Thanks for the correction. The trouble is that while saying this
little may be sufficient for builtins that correspond to functions fully
specified elsewhere (e.g., in the C standard) it's inadequate for
__builtin_alloca because the function it corresponds to has compiler-specific
semantics. On Linux, for example, the alloca() man page says:
The alloca() function is machine- and compiler-dependent.
As an example, one important detail that I happen to be looking for is the
scope of the storage obtained by __builtin_alloca: is it the whole function or
just the block in which it's invoked, does it depend on the language (C vs
C++), or is it subject to some compiler options?
I see inconsistent behavior with the following test case (and some others like
it) and I'm trying to understand what's expected:
$ cat x.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -O2 -Wall
-Wextra -Wpedantic -xc++ x.c && ./a.out
#if __cplusplus
# define alloca(N) __builtin_alloca (N)
#endif
void __attribute__ ((noinline, noclone)) foo (const int *p, int n) {
__builtin_printf ("%s(%p, %i)\n", __func__, p, n);
}
void inline __attribute__ ((always_inline)) bar (int n) {
foo ((int*)alloca (n), n);
foo ((int*)alloca (n), n);
if (n)
bar (n - 1);
}
int main (void)
{
bar (1);
}
x.c: In function ‘void foo(const int*, int)’:
x.c:6:51: warning: format ‘%p’ expects argument of type ‘void*’, but argument 3
has type ‘const int*’ [-Wformat=]
__builtin_printf ("%s(%p, %i)\n", __func__, p, n);
^
foo(0x3fffd7129da0, 1)
foo(0x3fffd7129d90, 1)
foo(0x3fffd7129d90, 0)
foo(0x3fffd7129d90, 0)
