Re: Trouble with alloca.h

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

_______________________________________________
MinGW-Users mailing list
[email protected]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.osdn.me/mailman/listinfo/mingw-users
Also: mailto:[email protected]?subject=unsubscribe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJcgrEFAAoJEMCtNsY0flo/woUP/3vslf2PvupebHryRVUvf99o
mmaI5O/armpNNdNWfjr8KtuNd4sRSWJIrO6iejz/+h3z87i8iv4PcBBjTDeG3CgU
zQfLsPCCtWDpNujvg1ByegozIuPS5aRm8oUZZ16sUuDCNjUj5gRDbPizo+BQRYQB
Je/Z54m8+3vlQz2Zro0C02Leuim9pDILoLWXWJt7o40TmQcpD2hrZLgcYLGwv2W6
QuFdnhBnNFyA9ij1zDXBaZsNC5GhvzPhaKwDCeyjizpGU+bLjkCuk7u2P/ds+PVY
seUGna19dlVSD00jvrRdUy3hkFLbBfoJYaYR75+PnY+vOXvofQKS2+pChPidXn/U
f+RYwuiX6TItQv+goklWRJl/pQvep3NvcozFWvQwvt+dVLbCbvq97k18Z0EGaGnd
rLM5pbry4MCuclKj7DEccHRmbnhIAUxBXVQnEKdZWtsKzKrByc0qD5oYgMBv/NaE
DfoXFrmY8BUynMJ637GGh1Zu6Wl6N9tSNBB2j2V66305tjczEOo1Bj3kbHmojcBz
rCfKPI1IxjdgcsKBP5ZqD/W0hUE7StKk9YukQWhzr/jg+DCxgqI+2MPfYMb1+vCA
l8teF/qLD6XqxuXxUGT4GF3vlcnVap/l3CnZmXTgfLZfyxkIO4nTuj0sDlrMrUhc
mK2SEg4P6JHEYRW5maey
=SB1x
-----END PGP SIGNATURE-----