RFR: 8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc [v3]

[Kim Barrett]

On Wed, 17 Apr 2024 20:49:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I'm aware of this discussion and looking into the issues, but a personal matter has intervened and it will take
>> me a while to respond properly.  Maybe next week.
>
> I opened https://bugs.openjdk.org/browse/JDK-8330539 so we don't lose track of this, but we can keep the discussion/voting here.

For the impatient, I suggest adopting mechanism 2, i.e. unconditionally
include <alloc.h> in globalDefinitions_gcc.hpp.

We can't include <alloca.h> in shared code, and there is a use in shared code
(in the relatively recently added JavaThread::pretouch_stack).

When I questioned whether we needed to include <alloca.h> at all, I referred
to a Linux man page I'd found on the internet (the same page mdoerr linked
to), which says (in part)

"By default, modern compilers automatically translate all uses of alloca()
into the built-in ..."

Apparently I should have kept digging, because it seems that page is
old/incorrect. A seemingly more recent Linux man page describes a different
way of handling it that is closer to what we're seeing, but still not quite
correct.

glibc's <stdlib.h> includes <alloca.h> if __USE_MISC is defined.
One of the ways __USE_MISC can become defined is if _GNU_SOURCE is defined,
and we define that for both gcc and clang toolchains.

We include <stdlib.h> in globalDefinitions_gcc.hpp. So when building with gcc,
globalDefinitions.hpp implicitly includes <alloca.h>.

The glibc definition of alloca is

#ifdef	__GNUC__
# define alloca(size)	__builtin_alloca (size)
#endif /* GCC.  */

So that explains why we don't need any explicit include of <alloca.h> when
building with gcc.  I expect there's something similar going on with Visual
Studio and Xcode/clang.  But apparently not with Open XLC clang.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1569930781