On Wed, 20 Nov 2019, Matthew Malcomson wrote: > I don't have much of a plan. > > The most promising lead I have is that libiberty/alloca.c has a similar > functionality but with macros to account for a special case.
The comment in libiberty/aclocal.m4 is: # We always want a C version of alloca() compiled into libiberty, # because native-compiler support for the real alloca is so !@#$% # unreliable that GCC has decided to use it only when being compiled # by GCC. This is the part of AC_FUNC_ALLOCA that calculates the # information alloca.c needs. This is the sort of thing that was relevant when GCC was built on lots of proprietary Unix systems with their system C compilers. Most of those proprietary Unix systems are long obsolete and are no longer supported by GCC. On the limited remaining set of host systems supported by GCC, there are a limited number of C++ compilers used to build most of the host code in GCC that is C++, and presumably a limited number of accompanying C compilers used to build libiberty. Now, libiberty is used by binutils more of which is written in C, but I doubt that expands the range of relevant host C compilers; the set of host OSes used nowadays is simply much smaller than it was when this code was written. So I'd suggest either completely eliminating C alloca from libiberty, or at least not building it at all when building with a compiler that defines __GNUC__. -- Joseph S. Myers jos...@codesourcery.com
