Re: Trouble with alloca.h

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

_______________________________________________
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)

iQIcBAEBAgAGBQJcgvfHAAoJEMCtNsY0flo/pucQAMpOKMHNN63kVWQH3X7ndOWw
M79EOv7sZb6UjOOLfSdb4jRSAmdqX3vXGOdJX/psXs8Nw1m9YFS63l6pRsSGBW1o
PNwYZ0Y5ijjE8FS6N0vAkw3xESJT0tWpTSRVUqrf/qKFkpeCgCxplLj/uBbmcZj8
Xu5OW3M2afgqEpRJ6htDlcUfmDq6IqShv9u0BXSPy60hn+32JQ1Ug6+CZYQ44EgT
7VSlBJ7s3iZ8AZvt3f1nqqqQoYZtxNmd5wJmzPiUz/TClTOcJpfV9MfFdP+ybSxb
oSDtFxV3CPrFyyIZQRQSIGwZEBrydAtazUaDCn4RsIVBAJ8rM1dDENe0cJV2I3lb
KfxjwR/IOTENhuIvY3ukMk64ZhRSLvT3QzfOkcmOARms26TTifr8O1LQcj7+6TCy
N6atKzCFYr9LIWhUGzsmnV+qyx/giQDkM1nbW/OkYPbZV5SFJbqPMLUpIzM1VL/d
CL679+EP60DXMp32JdRPfEbtrtXDG54FYv+YMgk3xbdJHxqRtPyrvRw+beevzB33
g6RajTEHKww3QaZwtHb6Vv2pWF9BRSnbKZjD4ujbXft5ntiKEtj/zeaILrgEFpyo
A/MaPjGZyNoIWN+XRhwxnucvqw10nmUQ6WMSHxVvAaquKFWad+GU10RsJWZUH6dg
wwfCfxHma11PCeXzWOoU
=3uug
-----END PGP SIGNATURE-----