On Thu, 28 Mar 2024 16:57:00 GMT, Joachim Kern <jk...@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

Reply via email to