[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Keith Marshall
Subject: Re: Gnulib's alloca.h used even when there is a system header
Date: Sat, 9 Mar 2019 19:25:06 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.


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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]