On 18/02/19 03:31, Eli Zaretskii wrote: >>> I'm not yet sure why Gnulib decides that it needs to use its own >>> alloca.h, >> >> It should not do so; it should defer to the host platform's own >> implementation, when one is provided. > > https://lists.gnu.org/archive/html/bug-gnulib/2019-02/msg00032.html If I follow the discussion thread, from this, I see this response from Bruno Haible: > GCC never inlines a function that calls alloca() or __builtin_alloca(). > 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. > > The mingw people have declared their new alloca() function as "always > inline", and GCC is decent enough to point us to the dilemma that it > cannot resolve. No disrespect of Bruno intended, but, at least with GCC-8.2, I can see no evidence whatsoever to support this claim; quite the contrary, in fact! Regardless of whether I adopt gnulib's (name equivalence) macro definition, a function-style macro definition, or the in-line function form, GCC generates *identical* object code in all three cases, at all optimization levels, (with the exception of a redundant, and entirely inconsequential addition[1] at -O0, for the in-line function case). With regard to Bruno's claim that expansion of the in-line form, within a loop, may precipitate a stack overflow which will be avoided by use of the macro form, this really does appear to be utter nonsense; the equivalence of the generated code is such that the allocation from the stack will grow *identically* for any of the suggested implementation forms, on each iteration of the loop. Thus, if a stack overflow will be precipitated by the in-line form of alloca() implementation, it will overflow just the same, with Bruno's favoured macro implementation. [1] The additional -O0 code comprises an immediate value store of the requested allocation size to stack memory, directly followed by a load of the stored value into the EAX register, and adjustment of the EAX value by a fixed bias, which is generated by a LEA instruction on EDX; at all other optimization levels, and even at -O0 with either of the macro styles of implementation, GCC does the sane thing, and loads the immediate value of the biased allocation request directly into EAX. So, while there may be a small incentive to favour the macro implementation over the in-line function, simply to avoid four useless instructions at -O0, those four instructions will have no effect on the behaviour of the generated code. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20190308/06cdf26a/attachment.sig>
Fork