On Tue, 6 Feb 2024 16:10:38 GMT, Magnus Ihse Bursie wrote:
>> make/modules/jdk.hotspot.agent/Lib.gmk line 31:
>>
>>> 29:
>>> 30: ifeq ($(call isTargetOs, linux), true)
>>> 31: SA_CFLAGS := -D_FILE_OFFSET_BITS=64
>>
>> We have two choices to feel a bit more comfortable:
>> 1) We
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 ; I put it again into our internal
>>
On Thu, 8 Feb 2024 07:41:02 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
> 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 incrementally with one
additional commit since the last revision:
On Thu, 8 Feb 2024 07:31:15 GMT, Magnus Ihse Bursie wrote:
> I don't like this approach. There must be better ways to achieve this, like
> inputting the correct value as input to the action, or setting it as a global
> gh variable. Where does even the `$JAVA_HOME_17_arm64` come from? Is it
>
On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer wrote:
> The
> [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
> for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke
> get-jtreg because the way to determine the build jdk was not
On Fri, 2 Feb 2024 15:49:59 GMT, Magnus Ihse Bursie wrote:
>> I wrote earlier:
>>
>>> There is one change that merit highlighting: In
>>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c, I kept the
>>> dlsym lookup for openat64, fstatat64 and fdopendir64, on non-BSD OSes (i.e.
>>>
On Wed, 7 Feb 2024 19:06:21 GMT, Weijun Wang wrote:
> Security changes look fine. Although I don't know how to remove those
> annotations later. A lot of compatibility impact.
In case you didn't see it, the warning message are listed in an attachment on
On Wed, 7 Feb 2024 19:28:11 GMT, Joe Darcy wrote:
>> After the "this-escape" lint warning was added to javac (JDK-8015831), the
>> base module was not updated to be able to compile with this warning enabled.
>> This PR makes the necessary changes to allow the base module to build with
>> the
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warning enabled.
Joe Darcy has updated the pull request
The
[change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke get-jtreg
because the macro to determine the build jdk was not correct.
I fix this by reverting to the originally proposed way to
On Wed, 7 Feb 2024 19:30:17 GMT, George Adams wrote:
> > Opened [JDK-8325444](https://bugs.openjdk.org/browse/JDK-8325444) and
> > trying a fix in https://github.com/RealCLanger/jdk/actions/runs/7820130826
>
> I like your approach, it feels more robust
Yeah, but didn't work. Here's a PR with
On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer wrote:
> The
> [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
> for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke
> get-jtreg because the macro to determine the build jdk was not
On Wed, 7 Feb 2024 19:29:02 GMT, Christoph Langer wrote:
> Opened [JDK-8325444](https://bugs.openjdk.org/browse/JDK-8325444) and trying
> a fix in https://github.com/RealCLanger/jdk/actions/runs/7820130826
I like your approach, it feels more robust
-
PR Comment:
On Sat, 3 Feb 2024 21:55:25 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1
On Wed, 7 Feb 2024 19:21:24 GMT, Christoph Langer wrote:
>> Okay, this one regressed GHA for new PRs:
>> https://github.com/stefank/jdk/actions/runs/7817217154/job/21324582843
>>
>>
>> Run # Build JTReg and move files to the proper locations
>> realpath: bootjdk/jdk: No such file or directory
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warning enabled.
Joe Darcy has updated the pull request
On Wed, 7 Feb 2024 15:59:00 GMT, Aleksey Shipilev wrote:
> Okay, this one regressed GHA for new PRs:
> https://github.com/stefank/jdk/actions/runs/7817217154/job/21324582843
>
> ```
> Run # Build JTReg and move files to the proper locations
> realpath: bootjdk/jdk: No such file or directory
>
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the
> Please review a patch to add support for Markdown syntax in documentation
> comments, as described in the associated JEP.
>
> Notable features:
>
> * support for `///` documentation comments in `JavaTokenizer`
> * new module `jdk.internal.md` -- a private copy of the `commonmark-java`
>
On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy wrote:
> Add policy statement about lint warnings to various langtools modules.
This pull request has now been integrated.
Changeset: 3a1f4d0f
Author:Joe Darcy
URL:
On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy wrote:
> Add policy statement about lint warnings to various langtools modules.
Marked as reviewed by jjg (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17718#pullrequestreview-1868462643
On Tue, 6 Feb 2024 02:28:32 GMT, Joe Darcy wrote:
> Add policy statement about lint warnings to various langtools modules.
lgtm
-
Marked as reviewed by vromero (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17718#pullrequestreview-1868464016
On Sat, 3 Feb 2024 21:55:25 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1
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 Thu, 7 Dec 2023 09:30:01 GMT, Xiaohong Gong wrote:
>> Currently the vector floating-point math APIs like
>> `VectorOperators.SIN/COS/TAN...` are not intrinsified on AArch64 platform,
>> which causes large performance gap on AArch64. Note that those APIs are
>> optimized by C2 compiler on
On Tue, 6 Feb 2024 17:54:24 GMT, Erik Joelsson wrote:
>> Over time, we have been better at addressing inconsistencies in the build,
>> but the exceptions put in place in compare.sh have not been updated to
>> reflect this.
>>
>> This attempts to make sure we only keep those exceptions that
28 matches
Mail list logo
