On Wed, 17 Apr 2024 20:49:37 GMT, Magnus Ihse Bursie <i...@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
