On 19/02/19 17:18, Eli Zaretskii wrote: >> From: Bruno Haible <br...@clisp.org> >> Cc: Eli Zaretskii <e...@gnu.org>, Paul Eggert <egg...@cs.ucla.edu> >> 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
