Re: Gnulib's alloca.h used even when there is a system header

[Keith Marshall]

On 19/02/19 17:18, Eli Zaretskii wrote:
>> From: Bruno Haible <address@hidden>
>> Cc: Eli Zaretskii <address@hidden>, Paul Eggert <address@hidden>
>> Date: Tue, 19 Feb 2019 00:32:24 +0100
>>
>> Hi Eli,
>>
>>>      ./alloca.h:40:18: error: inlining failed in call to always_inline 
>>> '__builtin_alloca': function not considered for inlining
>>>       #  define alloca __builtin_alloca
>>>                    ^
>>
>> GCC never inlines a function that calls alloca() or
>> __builtin_alloca().

With respect, while that may be true of ancient historical versions of
GCC, my own testing shows it to be untrue for modern releases; I cannot
reproduce[1] anything resembling the above diagnostic, unless I resort
to archaeological investigation, compiling with mingw32-gcc-3.4.5.  The
next version, which I still have available, is mingw32-gcc-4.8.2; with
that, and with all subsequent releases up to mingw32-gcc-8.2.0, other
than at -O0, GCC generates identical code for alloca() expressed as an
in-line function, to that which is generated when it is expressed as a
macro.  (Furthermore, the difference in code generated at -O0 is
inconsequential, and will have no effect on behaviour).

>> The reason is that if you call this function in a loop, then
>> without inlining it will consume a bounded amount of stack whereas
>> with inlining it might cause a stack overflow.

I'm sorry to say this, but that just seems disingenuous.  For every
version of GCC which I have available, *including* mingw32-gcc-3.4.5, if
I place a call to alloca(), *implemented as a macro*, within a loop,
then the stack grows on each iteration of the loop.  The growth is not
bounded, even for your macro implementation, with mingw32-gcc-3.4.5, but
for all versions from mingw32-gcc-4.8.2 onwards it *is* bounded, (by
calling __chkstk_ms(), before adjusting the stack pointer), for *both*
your macro implementation, and for in-line function expansion.

[1] Well, I actually can reproduce it, even with mingw32-gcc-8.2.0, but
*only* when I deliberately introduce the very bug which Eli has noted,
*and* I compile at -O0; at any other optimization level, this gnulib bug
seems to be optimized away, with __builtin_alloca() itself being
expanded to in-line intrinsic code, as intended.

-- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F

signature.asc
Description: OpenPGP digital signature