The jtreg test build/AbsPathsInImage.java fails with OOM when using
ubsan-enabled binaries (on Linux x86_64).
Reason seems to be that the ubsan-enabled binaries are much larger than
'normal' product binaries.
(for debug binaries the test is already disabled)
Error is :
java.lang.OutOfMemoryError:
On Tue, 3 Sep 2024 07:26:53 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/u
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleIm
On Mon, 2 Sep 2024 13:25:51 GMT, Matthias Baesken wrote:
>> We get a couple of warnings as errors on AIX because of unused variables or
>> functions , for example :
>> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/u
ems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)
Matthias Baesken has updated the pull request incrementally with one additional
commit since the la
On Tue, 3 Sep 2024 06:42:42 GMT, Julian Waters wrote:
>> At one stage we started using the idiom:
>>
>> (void) someFunc();
>>
>> to tell the compiler to not warn about the unused result. IIRC that stopped
>> working.
>
> Not entirely sure about clang, but casting to void to silence warnings sh
On Mon, 2 Sep 2024 11:43:20 GMT, Matthias Baesken wrote:
> We get a couple of warnings as errors on AIX because of unused variables or
> functions , for example :
> /priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleIm
ems to be related to the recent make changes
> 8339156: Use more fine-granular clang unused warnings
> https://bugs.openjdk.org/browse/JDK-8339156
> (we use clang too on AIX)
Matthias Baesken has updated the pull request incrementally with one additional
commit since the las
On Mon, 2 Sep 2024 12:17:57 GMT, Christoph Langer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> adjust indentation in X11Color.c
>
> src/java.desktop/unix/native/common/awt/X1
On Mon, 2 Sep 2024 12:30:43 GMT, Julian Waters wrote:
> Ah, the joys of supporting a platform that isn't covered by the Actions
> compile and test safety net :)
A Linux/clang build in the GHA would have probably shown at least a part of
those errors.
-
PR Comment: https://git.ope
We get a couple of warnings as errors on AIX because of unused variables or
functions , for example :
/priv/jenkins/client-home/workspace/openjdk-jdk-dev-aix_ppc64-opt/jdk/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:665:10:
error: unused variable 'exePath' [-Werror,-Wunused-variabl
On Wed, 14 Aug 2024 10:49:27 GMT, Matthias Baesken wrote:
> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now
> this build error (when using clang on Linux) :
> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
> We should bette
On Wed, 14 Aug 2024 13:01:09 GMT, Matthias Baesken wrote:
>> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now
>> this build error (when using clang on Linux) :
>> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
>> We
On Wed, 14 Aug 2024 10:49:27 GMT, Matthias Baesken wrote:
> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now
> this build error (when using clang on Linux) :
> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
> We should bette
> After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now
> this build error (when using clang on Linux) :
> `clang: error: invalid linker name in argument '-fuse-ld=lld'`
> We should better check for lld in the configure process if it is required
&g
After [JDK-8333189](https://bugs.openjdk.org/browse/JDK-8333189) I get now this
build error (when using clang on Linux) :
`clang: error: invalid linker name in argument '-fuse-ld=lld'`
We should better check for lld in the configure process if it is required with
clang .
-
Commit m
On Mon, 5 Aug 2024 12:30:25 GMT, Christoph Langer wrote:
> Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is
> available in the meanwhile, we can use it. I also correct the alphabetical
> ordering of the macOS platforms.
Marked as reviewed by mbaesken (Reviewer).
---
On Tue, 25 Jun 2024 11:20:38 GMT, Matthias Baesken wrote:
>> Sometimes it would be helpful to have configure-support for adding
>> additional ubsan check options.
>> E.g. support new configure option
>> '--with-additional-ubsan-checks=' .
>
> Matth
On Thu, 20 Jun 2024 11:31:05 GMT, Matthias Baesken wrote:
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
This pull request has now been
On Mon, 24 Jun 2024 08:46:10 GMT, Erik Joelsson wrote:
> We could have both --with-ubsan-checks= and --with-additional-ubsan-checks if
> you think it would be useful.
What are the preferences of the others ? Yeah it might be useful indeed (Kim
proposed a flag for replacing the checks in the o
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
Matthias Baesken has updated the pull request incrementally with one additional
commit s
On Fri, 21 Jun 2024 23:07:57 GMT, Kim Barrett wrote:
> [Just a drive-by comment, not a review and not planning to review.] As a
> user, syntactically I think I'd prefer something like the
> `with-ubsan[=parameters]` approach suggested in the the probably duplicate
> issue https://bugs.openjdk.
On Sat, 22 Jun 2024 07:21:15 GMT, Thomas Stuefe wrote:
> Stupid question, could I not just pass `--with-extra-cxxflags` or similar,
> and have the same effect?
Technically probably yes, but wouldn't that be cflags AND cxxflags ?
Another positive point with this PR - the added settings show up
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
Matthias Baesken has updated the pull request incrementally with one additional
commit s
On Thu, 20 Jun 2024 12:48:40 GMT, Matthias Baesken wrote:
>> Sometimes it would be helpful to have configure-support for adding
>> additional ubsan check options.
>> E.g. support new configure option
>> '--with-additional-ubsan-checks=' .
>
> Matth
On Thu, 20 Jun 2024 11:31:05 GMT, Matthias Baesken wrote:
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
Thanks for the advice, UTIL_ARG_WITH
> Sometimes it would be helpful to have configure-support for adding additional
> ubsan check options.
> E.g. support new configure option
> '--with-additional-ubsan-checks=' .
Matthias Baesken has updated the pull request incrementally with one additional
commit s
Sometimes it would be helpful to have configure-support for adding additional
ubsan check options.
E.g. support new configure option
'--with-additional-ubsan-checks=' .
-
Commit messages:
- JDK-8334618
Changes: https://git.openjdk.org/jdk/pull/19802/files
Webrev: https://webrevs
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/Red
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/Red
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/Red
When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
flag --enable-ubsan), in a lot of jfr related tests like
compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr
this oob error can be seen :
/jdk/src/hots
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote:
> Currently we run into some alignment related issues when building with
> '--enable-ubsan' . Those errors already occur in the build. Fixing them might
> take some time and maybe also some discussion if it is wort
On Mon, 29 Apr 2024 12:15:55 GMT, Matthias Baesken wrote:
> Currently we run into some alignment related issues when building with
> '--enable-ubsan' . Those errors already occur in the build. Fixing them might
> take some time and maybe also some discussion if it is wort
Currently we run into some alignment related issues when building with
'--enable-ubsan' . Those errors already occur in the build. Fixing them might
take some time and maybe also some discussion if it is worth the effort ,
So for now the alignment related checks should be disabled to get the UBSA
On Wed, 20 Mar 2024 05:44:48 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 11 commits:
>
> - Merge branch '
On Fri, 12 Apr 2024 12:26:06 GMT, Magnus Ihse Bursie wrote:
> Unfortunately, after
> [JDK-8329704](https://bugs.openjdk.org/browse/JDK-8329704) AIX fails to
> build. The reason is that libjli is specially treated on AIX, and built like
> a static library. I tried to compensate for this (and ha
On Tue, 26 Mar 2024 19:30:01 GMT, Magnus Ihse Bursie wrote:
> On AIX, we need a static libjli, since the linker cannot find other libraries
> (like libjvm.so and libjava.so) using a relative path, as on other platforms.
>
> However, for reasons unclear, we still build a dynamic libjli.so on AIX
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/C
On Tue, 26 Mar 2024 09:21:20 GMT, Matthias Baesken wrote:
> After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in
> the AIX build into this failure :
>
> /opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
> gmake[3]: *** [lib/C
After [JDK-8328824](https://bugs.openjdk.org/browse/JDK-8328824), we run in the
AIX build into this failure :
/opt/freeware/bin/bash: -c: line 1: syntax error near unexpected token `('
gmake[3]: *** [lib/CoreLibraries.gmk:194:
/openjdk/nb/aix_ppc64/jdk-dev-opt/support/native/java.base/libjli_sta
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 Tue, 12 Mar 2024 16:02:41 GMT, Matthias Baesken wrote:
> > Please re-test.
>
> Hi Magnus, thanks for the adjustments. I reenabled your patch in our
> build/test queue .
Builds and test results on AIX (product and fastdebug) are fine with the latest
version of the PR .
--
On Tue, 12 Mar 2024 15:24:21 GMT, Magnus Ihse Bursie wrote:
> Please re-test.
Hi Magnus, thanks for the adjustments. I reenabled your patch in our
build/test queue .
-
PR Comment: https://git.openjdk.org/jdk/pull/18172#issuecomment-1992009593
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.
>> T
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.
>> T
On Fri, 23 Feb 2024 12:33:48 GMT, Magnus Ihse Bursie wrote:
> > We had the PR in our SAP internal build/test queue, so issues seen with it.
>
> What issues did you see? Or was that a typo for "no issues"?
Sorry Magnus, tests were fine no issues were observed.
-
PR Comment: https:/
On Fri, 23 Feb 2024 11:01:47 GMT, Magnus Ihse Bursie wrote:
> Just to confirm: this PR passes tier 1-5.
We had the PR in our SAP internal build/test queue, so issues seen with it.
-
PR Comment: https://git.openjdk.org/jdk/pull/17955#issuecomment-1961232277
On Tue, 6 Feb 2024 08:05:14 GMT, Matthias Baesken wrote:
>>> I hope finally the AIX part of this PR is done.
>>
>> Thanks for the AIX related effort ; I put it again into our internal
>> build/test queue.
>
>>
>> Thanks for the AIX related effort ;
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 increme
On Mon, 5 Feb 2024 14:15:44 GMT, Matthias Baesken wrote:
>
> Thanks for the AIX related effort ; I put it again into our internal
> build/test queue.
With the latest commit the build again fails on AIX with this error
/jdk/src/java.base/unix/native/libnio/ch/UnixFileDispatcherImpl
On Mon, 5 Feb 2024 14:03:45 GMT, Magnus Ihse Bursie wrote:
> I hope finally the AIX part of this PR is done.
Thanks for the AIX related effort ; I put it again into our internal build/test
queue.
-
PR Comment: https://git.openjdk.org/jdk/pull/17538#issuecomment-1927105669
On Mon, 5 Feb 2024 12:38:03 GMT, Magnus Ihse Bursie wrote:
> It seems like the statvfs64 is a pre-existing bug in AIX in that case. I have
> not removed any statvfs64 for AIX; all such changes are guarded by `#ifdef
> _ALLBSD_SOURCE`, which I presume is not defined on AIX.
>
> I recommend that
On Mon, 5 Feb 2024 12:17:33 GMT, Joachim Kern wrote:
> Yes, if statvfs64() is replaced by statvfs() in the code, we will fallback on
> AIX to 32-Bit. _LARGE_FILES really does not help in this case!
Thanks for confirming. I think we do not want to fallback on AIX, so the <*>64
variant needs to
On Fri, 2 Feb 2024 06:55:19 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 increme
On Fri, 2 Feb 2024 06:55:19 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 increme
On Thu, 1 Feb 2024 13:47:45 GMT, Matthias Baesken wrote:
>> After adding this additional patch I fully build fastdebug on AIX (hav to
>> admit it does not look very nice).
>>
>>
>> diff --git
>> a/src/java.desktop/share/native/libawt/java2d/pipe/Buffere
On Wed, 31 Jan 2024 09:19:39 GMT, Matthias Baesken wrote:
>> Magnus Ihse Bursie has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull requ
On Thu, 1 Feb 2024 09:04:47 GMT, Magnus Ihse Bursie wrote:
> I added a compile-time check that hotspot on AIX is indeed compiled with
> _LARGE_FILES.
>
> @MBaesken Are you happy with this PR now?
Thanks for adding this, I approved the PR .
-
PR Comment: https://git.openjdk.org/jd
On Tue, 30 Jan 2024 12:25:47 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 _LAR
On Tue, 30 Jan 2024 14:15:57 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 with a
On Wed, 31 Jan 2024 08:49:58 GMT, Magnus Ihse Bursie wrote:
> I suspect this worry of yours were more directed at the change for the JDK
Yes it is more a general worry, not especially related to Hotspot.
We could also add some kind of check (e.g. static assert or configure check)
to address it
On Mon, 29 Jan 2024 13:13:44 GMT, Matthias Baesken 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
On Tue, 30 Jan 2024 13:54:45 GMT, Magnus Ihse Bursie wrote:
> I'd appreciate if you could take the latest version for a spin, particularly
> a debug build...
Yes we pick up the latest version of the PR in a couple of hours for the
build+'lots of tests' (and this includes a fastdebug too).
--
On Tue, 30 Jan 2024 13:02:53 GMT, Magnus Ihse Bursie wrote:
> @MBaesken You gotta be kidding me... They just put in a `#define open open64`
> in a convenient place? 😞
>
> But why do only slowdebug fail? Weird.
Yes there is a nice define in the AIX header
ifdef _LARGE_FILES
#define openope
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.
AIX fastdebug build fails with the patch, build error is
/
On Mon, 29 Jan 2024 13:54:35 GMT, Joachim Kern wrote:
> Why not CFLAGS_OS_DEF_JVM="-DAIX -D_LARGE_FILES" as the equivalent on Linux
I think this PR is intended to be just about the JDK libs, not JVM compilation.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17538#discussion
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.
I put it into our build/test patch list to see how it behave
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 _LARGE_F
On Mon, 22 Jan 2024 12:19:25 GMT, Sam James wrote:
> Could someone run the other commands again for older branches for me as well?
> I don't have access.
Will look into 17 as well. Might make sense to have some other minor backports
to jdk17u-dev before, to make the backport easier (maybe [a
On Fri, 19 Jan 2024 10:37:42 GMT, Sam James wrote:
>> The LFS64 symbols provided by glibc are not part of any standard and were
>> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
>> This commit replaces the usage of LFS64 symbols with their regular
>> counterparts an
On Fri, 12 Jan 2024 13:32:28 GMT, Julian Waters wrote:
>As I mentioned above, the autoconf inserting of those compiler flags can be
>disabled by setting ac_prog_cc_stdc and >ac_prog_cxx_stdcxx to readonly empty
>values. It's also a workaround, but is slightly less hacky than filtering out
>the
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote:
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
> -std=gnu++11 by default to CXX in the configure process .
> This is not really wanted so better remove / filter out those -std* flags
> added by autoc
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out those -std* flags
>>
On Thu, 11 Jan 2024 14:31:47 GMT, Matthias Baesken wrote:
>> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
>> -std=gnu++11 by default to CXX in the configure process .
>> This is not really wanted so better remove / filter out any -std* flags
>> a
On Fri, 12 Jan 2024 06:32:34 GMT, Kim Barrett wrote:
> > Thanks! We may switch to clang 14 on MacOS at some point of time, but it's
> > better to have that disentangled. Some people build JDK 11 and 23 on the
> > same machine and that is easier if they don't have to switch Xcode.
>
> I think t
On Thu, 11 Jan 2024 13:54:01 GMT, Christoph Langer wrote:
> Makes sense. It's the same pattern.
I adjusted the second GREP too and removed the` if test` .
-
PR Comment: https://git.openjdk.org/jdk/pull/17301#issuecomment-1887318284
for some time for CFLAGS and CXXFLAGS ( see
> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that
> dates back to JDK 9.
>
> See the discussion about this issue :
> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html
Matthias Baesken has updated the pu
for some time for CFLAGS and CXXFLAGS ( see
> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that
> dates back to JDK 9.
>
> See the discussion about this issue :
> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html
Matthias Baesken has updated the pu
On Thu, 11 Jan 2024 11:19:01 GMT, Magnus Ihse Bursie wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adjust GREP call
>
> make/autoconf/toolchain.m4 line 395:
>
>> 393:
On Thu, 11 Jan 2024 11:06:02 GMT, Christoph Langer wrote:
> > Strange, I noticed that for some reason the
> > UTIL_GET_NON_MATCHING_VALUES(cxx_filtered, $CXX, -std=c++11 -std=gnu++11)
> > seems not to remove the flags as expected, did I misinterpret how
> > UTIL_GET_NON_MATCHING_VALUES works ?
for some time for CFLAGS and CXXFLAGS ( see
> TOOLCHAIN_POST_DETECTION in make/autoconf/toolchain.m4) that
> dates back to JDK 9.
>
> See the discussion about this issue :
> https://mail.openjdk.org/pipermail/build-dev/2024-January/042551.html
Matthias Baesken has updated the pu
On Wed, 10 Jan 2024 13:11:38 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary -std=c++17 option in Li
On Tue, 9 Jan 2024 17:03:43 GMT, Julian Waters wrote:
> Rather than filtering through the added flags like this, is it possible to
> figure out why macOS trips the C++11 heuristic and fix the problem there?
That might be a bit tricky, because on my macOS test machine, with a self
compiled auto
On Mon, 8 Jan 2024 10:16:21 GMT, Matthias Baesken wrote:
> It was observed, that autoconf 2.72 added on macOS x86_64 the flag
> -std=gnu++11 by default to CXX in the configure process .
> This is not really wanted so better remove / filter out any -std* flags added
> by autoconf
It was observed, that autoconf 2.72 added on macOS x86_64 the flag -std=gnu++11
by default to CXX in the configure process .
This is not really wanted so better remove / filter out any -std* flags added
by autoconf from CC/CXX .
Seems we have something similar for some time for CFLAGS and CXXFLA
On Fri, 3 Nov 2023 14:46:39 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>
>> One solution is to save
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote:
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
This pull request has now been integrated.
Changeset: b9983c72
Author:Matthias Baesken
URL:
On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken wrote:
>> Increase javacserver connection timeout values and max retry attempts for
>> better make stability on some slower machines.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Adjust WAIT_BETWEEN_CONNECT_AT
On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken wrote:
> Increase javacserver connection timeout values and max retry attempts for
> better make stability on some slower machines.
I adjusted the WAIT_BETWEEN_CONNECT_ATTEMPTS; Let's how this works.
-
PR Com
Increase javacserver connection timeout values and max retry attempts for
better make stability on some slower machines.
-
Commit messages:
- JDK-8318961
Changes: https://git.openjdk.org/jdk/pull/16397/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16397&range=00
Issue:
On Wed, 27 Sep 2023 08:18:45 GMT, Matthias Baesken wrote:
> Running jtreg tests with make test, for example
> make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX
> without setting the number of JOBS manually.
> We get this error message:
> Error
On Thu, 28 Sep 2023 12:57:07 GMT, Matthias Baesken wrote:
>> Running jtreg tests with make test, for example
>> make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX
>> without setting the number of JOBS manually.
>> We get this error message:
ded ints, so
> better print ints in the makefile by using %d .
Matthias Baesken has updated the pull request incrementally with one additional
commit since the last revision:
Add 0.5 to avoid rounding issues
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15941/files
- new:
On Wed, 27 Sep 2023 17:09:04 GMT, Erik Joelsson wrote:
> To work around this, perhaps add 0.5 to c before converting to int?
Hi Erik, sure we can do so , I adjusted the change.
-
PR Comment: https://git.openjdk.org/jdk/pull/15941#issuecomment-1739103028
On Wed, 27 Sep 2023 12:15:18 GMT, Magnus Ihse Bursie wrote:
> Looks good. Have you verified that this works with nawk as well as old gawk
> versions?
On AIX I have both nawk and gawk on the machine and both work with the change.
On Linux I have just gawk (more recent one) and this works too.
-
Running jtreg tests with make test, for example
make test TEST="jtreg:test/jdk/java/util/prefs" fails currently on AIX without
setting the number of JOBS manually.
We get this error message:
Error: Bad use of -concurrency
Log of cmdargs shows :
-vmoption:-Xmx768m
-agentvm
-verbose:fail,error,summ
On Mon, 4 Sep 2023 07:40:11 GMT, Matthias Baesken wrote:
>> After looking at the build results of a jdk22 build on RHEL 8.4 Linux
>> ppc64le that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0
>> devkit we observed those unwanted paths in libsplashscreen
On Fri, 1 Sep 2023 11:02:36 GMT, Matthias Baesken wrote:
> After looking at the build results of a jdk22 build on RHEL 8.4 Linux ppc64le
> that uses a ppc64le-linux-gnu-to-ppc64le-linux-gnu-fedora27-gcc11.3.0
> devkit we observed those unwanted paths in libsplashscreen.so .
> See t
1 - 100 of 209 matches
Mail list logo
