On 08/03/19 18:54, Eli Zaretskii wrote: >> From: Keith Marshall >> Date: Fri, 8 Mar 2019 18:14:28 +0000 >> >>> 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! > > That was also my conclusion. I've now repeated my own analysis, with every version of mingw32-gcc that I still have to hand; the list comprises: GCC-3.4.5 GCC-4.8.2 GCC-4.9.3 GCC-5.3.0 GCC-6.3.0 GCC-7.3.0 GCC-8.2.0 It turns out that Bruno's claim may be valid, in the particular case of GCC-3.4.5 alone; in every other case, his claim is bogus. As every version of mingwrt which has been published, since the publication of mingw32-gcc-4.8.2, (and possibly earlier mingw32-gcc-4.x releases), is incompatible with mingw32-gcc-3.4.5 anyway, any argument that we must not adopt the in-line expansion of alloca() seems tenuous at best. There may still be a non-imperative justification for adopting the macro implementation, since it does suppress three uselessly redundant instructions, (I previously said four, but it's actually one immediate to register addition replaced by an immediate to memory store, a memory to register load, a register indirect offset address load, and then one register to register addition), when compiling at -O0; it could also be tentatively justified, perhaps conditionally, if we want to support any users who may still need to compile their own modern mingwrt, for use with a legacy mingw32-gcc-3.4.5 installation. The latter configuration is not one I particularly care to support, but I'm not vehemently opposed to it; neither do I have an especially strong opinion regarding potential merits of an in-line implementation, in this particular case. What do other users think? > Please help me to revive that discussion, as it seems to have > stalled, and my recent ping didn't help. I can certainly post a rebuttal of Bruno's bogus claim; is the gnulib list open to non-subscriber postings? I'd still welcome opinions from other MinGW users, regarding the status quo of our current mingwrt implementation. -- 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/1f2a76e7/attachment.sig>
Fork