RFR: JDK-8329257: AIX: Switch HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc

[Thomas Stuefe]

On Thu, 28 Mar 2024 16:57:00 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect clang by another name, and it uses the clang toolchain in the JDK build. Thus the old xlc toolchain was removed by [JDK-8327701](https://bugs.openjdk.org/browse/JDK-8327701).
>> Now we also switch the HOTSPOT_TOOLCHAIN_TYPE from xlc to gcc, removing the last xlc rudiment.
>> This means merging the AIX specific content of utilities/globalDefinitions_xlc.hpp and utilities/compilerWarnings_xlc.hpp into the corresponding gcc files on the on side and removing the defined(TARGET_COMPILER_xlc) blocks in the code, because the defined(TARGET_COMPILER_gcc) blocks work out of the box for the new AIX compiler.
>> The rest of the changes are needed because of using utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about ill formatted printf
>
> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 50:
> 
>> 48:   #undef malloc
>> 49:   extern void *malloc(size_t) asm("vec_malloc");
>> 50: #endif
> 
> This `#if` is not needed if we are building on AIX 7.2 TL5 SP7 or higher. This is the case in our build environment, but I think IBM is still building with SP5, which would run into build errors if I remove this `#if` now.

While looking at this, I noticed that my question in https://github.com/openjdk/jdk/pull/14146#discussion_r1207078176 and followups had never been answered. Do you know the answers now?

Quoting myself:

> So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free?
> Removing that define and hard-coding it here assumes ... pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so.
> I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future.

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

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