On Thu, 2 May 2024 09:54:14 GMT, Joachim Kern wrote:
> We need to find a better way to handle alloca on AIX.
>
> See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257,
> e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in
> which thr
We need to find a better way to handle alloca on AIX.
See the discussion in the PR for https://bugs.openjdk.org/browse/JDK-8329257,
e.g. https://github.com/openjdk/jdk/pull/18536#discussion_r1568650313 in which
three alternatives are suggested. Quoting:
Let me summarize the choices we have and
On Tue, 30 Apr 2024 14:39:29 GMT, Magnus Ihse Bursie wrote:
>> Ok for me. Let's hear what @kimbarrett thinks.
>
> It might be easier to get input if you create a new PR with the change. This
> discussion is hidden deep down in a closed PR.
I will do after labor day and create a PR with this
On Tue, 30 Apr 2024 12:46:31 GMT, Magnus Ihse Bursie wrote:
>> I got it. And what about simply disabling the `__STRICT_ANSI__` with
>> `CFLAGS_OS_DEF_JVM="-DAIX -D_LARGE_FILES -U__STRICT_ANSI__"` in
>> flags-cflags.m4 for AIX. This worked too. The build is fine.
>
> So what you are saing is
On Tue, 30 Apr 2024 10:19:30 GMT, Magnus Ihse Bursie wrote:
>> The compiler flag introducing __STRICT_ANSI__ is -std=c++14. If I omit this
>> explicit compiler flag the default is used, which is also c++14. But the
>> default does not set __STRICT_ANSI__ but 2 other defines. I will try a build
On Mon, 29 Apr 2024 16:17:13 GMT, Joachim Kern wrote:
>> For the impatient, I suggest adopting mechanism 2, i.e. unconditionally
>> include in globalDefinitions_gcc.hpp.
>>
>> We can't include in shared code, and there is a use in shared code
>> (in the relati
On Thu, 18 Apr 2024 04:26:21 GMT, Kim Barrett wrote:
>> 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 in
On Tue, 16 Apr 2024 09:15:19 GMT, Magnus Ihse Bursie wrote:
>> That was kind of where the discussion started, and which Kim did not like.
>> If I read him correctly, his suggestion was instead to place:
>>
>> #if defined(_AIX)
>> #include
>> #endif
>>
>> in the files where `alloca` is needed
On Wed, 10 Apr 2024 22:14:33 GMT, Kim Barrett wrote:
>> That build failure in shared code does not happen with Xcode clang, gcc, or
>> Visual Studio, even though none of them appear to have a relevant define or
>> include. So the clang variant being used for AIX is different from the Xcode
>>
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern 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 bu
compilerWarnings_gcc.hpp the compiler is much more nagging about
> ill formatted printf
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
my_disclaim64 already removed by other PR
-
Changes:
- all: https://git
On Wed, 10 Apr 2024 13:19:50 GMT, Martin Doerr wrote:
>> Currently XLC16 but looking to upgrade to XLC17 on the minimum supported
>> level for it (So it wouldn't be SP7 at present). Thanks for the ping - we
>> have no current plans to increase to SP7.
>
> Seems like we need to keep it. This is
compilerWarnings_gcc.hpp the compiler is much more nagging about
> ill formatted printf
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
saver solution
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18536/files
compilerWarnings_gcc.hpp the compiler is much more nagging about
> ill formatted printf
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
replaced pragma alloca and include alloca by compiler define
-
Changes:
- a
compilerWarnings_gcc.hpp the compiler is much more nagging about
> ill formatted printf
Joachim Kern has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains five commits:
- Merge master
- cosmetic changes
- version check not needed
On Wed, 10 Apr 2024 10:07:02 GMT, Martin Doerr wrote:
>> Is the comment in front of
>> https://github.com/openjdk/jdk/blob/51ed69a586105b707ae616f9eba898449bf9fba7/src/hotspot/os/aix/os_aix.cpp#L28
>> still correct? Seems like it should get replaced. See
>>
compilerWarnings_gcc.hpp the compiler is much more nagging about
> ill formatted printf
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
cosmetic changes
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18536/files
On Wed, 10 Apr 2024 00:51:22 GMT, Kim Barrett wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 36:
>>
>>> 34: #if defined(_AIX)
>>> 35: #include
>>> 36: #endif
>>
>> I would much rather see this include added in the few places it was actually
>> needed, rather than being
On Tue, 9 Apr 2024 18:32:04 GMT, Kim Barrett wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> version check not needed anymore
>
> src/hotspot/share/utilities/byteswap.hpp line 2:
>
On Tue, 9 Apr 2024 17:00:56 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> version check not needed anymore
>
> src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp line 4
On Tue, 9 Apr 2024 16:59:39 GMT, Thomas Stuefe wrote:
>> Hi Thomas, `maxDisclaimSize` is of type `unsigned int`; therefore I get the
>> following warning:
>>
>> os/aix/os_aix.cpp:314:42: error: format specifies type 'unsigned long' but
>> the argument has type 'unsigned int'
compilerWarnings_gcc.hpp the compiler is much more nagging about
> ill formatted printf
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
version check not needed anymore
-
Changes:
- all: https://git.openjdk.org/jdk/p
On Tue, 2 Apr 2024 14:48:49 GMT, Martin Doerr wrote:
>> My question is, do we need this block, because now already configure warns
>> about an outdated compiler, or is a warning to weak and we want to force
>> this error here?
>
> I think that building with xlc 16 is no longer possible because
compilerWarnings_gcc.hpp the compiler is much more nagging about
> ill formatted printf
Joachim Kern has updated the pull request incrementally with one additional
commit since the last revision:
Followed the proposals
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18536
On Tue, 2 Apr 2024 11:28:30 GMT, Joachim Kern wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 103:
>>
>>> 101: #endif
>>> 102:
>>> 103: #if !defined(LINUX) && !defined(_ALLBSD_SOURCE) && !defined(_AIX)
>>
>&g
On Fri, 29 Mar 2024 08:06:01 GMT, Thomas Stuefe 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
On Thu, 28 Mar 2024 17:33:29 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 83:
>>
>>> 81: #error "xlc version not supported, macro __open_xl_version__ not
>>> found"
>>> 82: #endif
>>> 83: #endif // AIX
>>
>> This `#ifdef _AIX` might be obsolete,
On Fri, 29 Mar 2024 07:39:06 GMT, Thomas Stuefe 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
On Fri, 29 Mar 2024 07:25:30 GMT, Thomas Stuefe 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
On Fri, 29 Mar 2024 07:19:33 GMT, Thomas Stuefe wrote:
>> src/hotspot/os/aix/loadlib_aix.cpp line 120:
>>
>>> 118: (lm->is_in_vm ? '*' : ' '),
>>> 119: (uintptr_t)lm->text, (uintptr_t)lm->text + lm->text_len,
>>> 120: (uintptr_t)lm->data, (uintptr_t)lm->data + lm->data_len,
>>
On Fri, 29 Mar 2024 07:21:43 GMT, Thomas Stuefe 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
On Tue, 2 Apr 2024 09:14:10 GMT, Joachim Kern wrote:
>> Other than that, and kind of depending on your answer: How important is it
>> that we catch every use of the original malloc? Can be safely mix the
>> original malloc with vec_malloc if logging is not involved?
>>
On Fri, 29 Mar 2024 07:59:05 GMT, Thomas Stuefe wrote:
>> 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
On Fri, 29 Mar 2024 05:23:57 GMT, Julian Waters wrote:
> > The rest of the changes are needed because of using
> > utilities/compilerWarnings_xlc.hpp the compiler is much more nagging about
> > ill formatted printf
>
> Did you mean compilerWarnings_gcc.hpp?
Yes, you're right. I fixed it.
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern 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 bu
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern 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 bu
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
On Tue, 12 Mar 2024 15:27:29 GMT, Magnus Ihse Bursie 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.
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie 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.
>>
On Mon, 11 Mar 2024 08:59:03 GMT, Joachim Kern wrote:
>> make/autoconf/flags-cflags.m4 line 687:
>>
>>> 685: PICFLAG="-fPIC"
>>> 686: PIEFLAG="-fPIE"
>>> 687: elif test "x$TOOLCHAIN_TYPE" = xclang && tes
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie 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.
>>
On Fri, 8 Mar 2024 15:31:18 GMT, Magnus Ihse Bursie wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert SEARCH_PATH changes
>
> make/autoconf/flags-cflags.m4 line 687:
>
>> 685: PICFLAG="-fPIC"
>>
On Fri, 8 Mar 2024 15:48:08 GMT, Magnus Ihse Bursie 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.
>>
On Tue, 5 Mar 2024 08:41:00 GMT, Kim Barrett wrote:
> > > What does this mean? That you are not using xlc at all? Or is it clang
> > > but still with an xlc frontend, so all xlc flags etc need to stay?
> >
> >
> > The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the
> >
On Thu, 15 Feb 2024 12:49:26 GMT, Julian Waters wrote:
> > > I see. I believe I wrote that piece of code, but I'd clearly forgotten
> > > that. Thanks! :)
> >
> >
> > No, this was added by me, because this was the root point to still resolve
> > to globalDefinitions_xlc.hpp even with
On Thu, 15 Feb 2024 12:29:50 GMT, Magnus Ihse Bursie wrote:
> I see. I believe I wrote that piece of code, but I'd clearly forgotten that.
> Thanks! :)
No, this was added by me, because this was the root point to still resolve to
globalDefinitions_xlc.hpp even with toolchain clang
On Thu, 15 Feb 2024 10:40:53 GMT, Magnus Ihse Bursie wrote:
> What does this mean? That you are not using xlc at all? Or is it clang but
> still with an xlc frontend, so all xlc flags etc need to stay?
The `xlc` toolchain is for the compiler versions up to 16 (xlclang++); the
`clang`
On Wed, 14 Feb 2024 22:43:37 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of IBM
> Open XL C/C++. SAP dropped support for older versions in JDK 22, only
> supporting the version specified in this change.
>
> I need someone from the aix-ppc
On Thu, 8 Feb 2024 14:47:26 GMT, Joachim Kern wrote:
>> And also `#define statvfs statvfs64` is not necessary with the same
>> explanation as for the `opendir` defines above -- sorry again.
>> The very only difference between statvfs and statvfs64 is that the
>> filesy
On Thu, 8 Feb 2024 09:03:10 GMT, Joachim Kern wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Once more, remove AIX dirent64 et al defines
>
> And also `#define statv
On Thu, 8 Feb 2024 07:44:18 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Tue, 6 Feb 2024 08:18:14 GMT, Magnus Ihse Bursie wrote:
>> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
>> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
>> native libraries.
>
> Magnus Ihse Bursie has updated the pull request
On Mon, 5 Feb 2024 12:07:45 GMT, Matthias Baesken wrote:
> Current commit compiles nicely on AIX. One issue we might still have
> statvfs/statvfs64 is not mentioned here in the table of functions/structs
> redefined on AIX
>
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
src/java.prefs/unix/native/libprefs/FileSystemPreferences.c
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
src/java.base/share/native/libjli/wildcard.c line 109:
>
On Tue, 23 Jan 2024 15:42:55 GMT, Magnus Ihse Bursie wrote:
> Similar to [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we
> should use -D_FILE_OFFSET_BITS=64, and not -D_LARGEFILE64_SOURCE in the JDK
> native libraries.
make/autoconf/flags-cflags.m4 line 488:
> 486:
On Mon, 29 Jan 2024 11:44:34 GMT, Magnus Ihse Bursie wrote:
> In the same spirit as
> [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), we should adapt
> the AIX-specific code in hotspot so it uses the well-defined posix ``
> functions, instead of `64`. By setting the define
58 matches
Mail list logo
