Re: RFR: 8287174: Remove deprecated configure arguments

2022-05-23 Thread David Holmes
On Mon, 23 May 2022 17:25:30 GMT, Magnus Ihse Bursie wrote: > We have a bunch of configure arguments that has been deprecated for multiple > releases. These should be removed. In effect, this will raise an error > instead of a warning if these argument is included on the command line for >

Integrated: 8286262: Windows: Cleanup deprecation warning suppression

2022-05-23 Thread Kim Barrett
On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2)

Re: RFR: 8286262: Windows: Cleanup deprecation warning suppression [v2]

2022-05-23 Thread Kim Barrett
> Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected

Re: RFR: 8286262: Windows: Cleanup deprecation warning suppression

2022-05-23 Thread Kim Barrett
On Tue, 17 May 2022 06:30:03 GMT, David Holmes wrote: >> Please review this cleanup of deprecation warning suppression when building >> for Windows. >> >> This change consists of several parts. >> >> (1) Remove the global deprecation warning suppression when building HotSpot >> for Windows. >>

Integrated: 8287155: Additional make typos

2022-05-23 Thread Magnus Ihse Bursie
On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable > to the entire JDK. :-( Keep the fixes for the problems found in the make > directory, though. This pull request has now been integrated. Changeset:

Re: RFR: 8284209: Replace remaining usages of 'a the' in source code [v2]

2022-05-23 Thread Alexey Ivanov
> Replaces usages of articles that follow each other in all combinations: > a/the, an?/an?, the/theā€¦ > > It's the last issue in the series, and it still touches different areas of > the code. Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The

Re: RFR: 8287155: Additional make typos

2022-05-23 Thread Iris Clark
On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable > to the entire JDK. :-( Keep the fixes for the problems found in the make > directory, though. Marked as reviewed by iris (Reviewer). - PR:

Re: RFR: 8287155: Additional make typos

2022-05-23 Thread Lance Andersen
On Mon, 23 May 2022 10:04:14 GMT, Magnus Ihse Bursie wrote: > Testing ispell + shell magic to locate typos. It worked, but is not scalable > to the entire JDK. :-( Keep the fixes for the problems found in the make > directory, though. Marked as reviewed by lancea (Reviewer). -

Re: RFR: 8287174: Remove deprecated configure arguments

2022-05-23 Thread Aleksey Shipilev
On Mon, 23 May 2022 17:25:30 GMT, Magnus Ihse Bursie wrote: > We have a bunch of configure arguments that has been deprecated for multiple > releases. These should be removed. In effect, this will raise an error > instead of a warning if these argument is included on the command line for >

RFR: 8287174: Remove deprecated configure arguments

2022-05-23 Thread Magnus Ihse Bursie
We have a bunch of configure arguments that has been deprecated for multiple releases. These should be removed. In effect, this will raise an error instead of a warning if these argument is included on the command line for configure. The deprecated arguments stopped having any effect when they

Reproducible MacOS Codesign'ed builds?

2022-05-23 Thread Andrew Leonard
Hi, Has anyone looked into reproducible builds for codesign'd MacOS builds? Basically Apple codesigning is non-deterministic, which is not surprisingly I guess, so naturally makes reproducible builds a bit tricky. The general theme for this sort of issue seems to be to remove the signature before

Re: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3]

2022-05-23 Thread Andrew Haley
On Mon, 23 May 2022 16:12:34 GMT, Dmitry Chuyko wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the >> start. Currently they are enabled after feature detection and RR reverse >> debugger works incorrectly. >> >> New build configuration feature 'hardlse' is

Re: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v2]

2022-05-23 Thread Dmitry Chuyko
On Mon, 23 May 2022 16:05:16 GMT, Dmitry Chuyko wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the >> start. Currently they are enabled after feature detection and RR reverse >> debugger works incorrectly. >> >> New build configuration feature 'hardlse' is

Re: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3]

2022-05-23 Thread Dmitry Chuyko
> On AArch64 it is sometimes convenient to have LSE atomics right from the > start. Currently they are enabled after feature detection and RR reverse > debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for > aarch64 type of build, then

Re: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v2]

2022-05-23 Thread Dmitry Chuyko
> On AArch64 it is sometimes convenient to have LSE atomics right from the > start. Currently they are enabled after feature detection and RR reverse > debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for > aarch64 type of build, then

Re: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions

2022-05-23 Thread Dmitry Chuyko
On Fri, 20 May 2022 08:36:28 GMT, Magnus Ihse Bursie wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the >> start. Currently they are enabled after feature detection and RR reverse >> debugger works incorrectly. >> >> New build configuration feature 'hardlse' is

Re: pre-submit tests for github PRs

2022-05-23 Thread Philip Race
Ah. -phil On 5/23/22 8:18 AM, Langer, Christoph wrote: Hi, that's because the PR is a based on a pre-loom version of master. Best regards Christoph -Original Message- From: build-dev On Behalf Of Philip Race Sent: Montag, 23. Mai 2022 17:14 To: Aleksey Shipilev ; Ioi Lam ;

RE: pre-submit tests for github PRs

2022-05-23 Thread Langer, Christoph
Hi, that's because the PR is a based on a pre-loom version of master. Best regards Christoph > -Original Message- > From: build-dev On Behalf Of Philip Race > Sent: Montag, 23. Mai 2022 17:14 > To: Aleksey Shipilev ; Ioi Lam ; > build-dev@openjdk.java.net > Subject: Re: pre-submit

Re: pre-submit tests for github PRs

2022-05-23 Thread Philip Race
BTW I am wondering whether I should believe this explanation since it does pass sometimes, eg : https://github.com/openjdk/jdk/pull/8820 How is that possible ? -phil On 5/23/22 8:05 AM, Aleksey Shipilev wrote: On 5/23/22 16:53, Ioi Lam wrote: On 5/23/2022 4:41 AM, Alan Bateman wrote: On

Re: pre-submit tests for github PRs

2022-05-23 Thread Aleksey Shipilev
On 5/23/22 16:53, Ioi Lam wrote: On 5/23/2022 4:41 AM, Alan Bateman wrote: On 22/05/2022 23:58, David Holmes wrote: GHA tests a range of OpenJDK ports, not just the "mainstream platforms". The existing linux-86 failures (and others) are due to the Loom integration which only fully supports a

Re: pre-submit tests for github PRs

2022-05-23 Thread Ioi Lam
On 5/23/2022 4:41 AM, Alan Bateman wrote: On 22/05/2022 23:58, David Holmes wrote: GHA tests a range of OpenJDK ports, not just the "mainstream platforms". The existing linux-86 failures (and others) are due to the Loom integration which only fully supports a couple of platforms and which

Re: pre-submit tests for github PRs

2022-05-23 Thread Alan Bateman
On 22/05/2022 23:58, David Holmes wrote: GHA tests a range of OpenJDK ports, not just the "mainstream platforms". The existing linux-86 failures (and others) are due to the Loom integration which only fully supports a couple of platforms and which broke all the other ports upon initial

Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments [v10]

2022-05-23 Thread Adam Sotona
> Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment

RFR: 8287155: Additional make typos

2022-05-23 Thread Magnus Ihse Bursie
Testing ispell + shell magic to locate typos. It worked, but is not scalable to the entire JDK. :-( Keep the fixes for the problems found in the make directory, though. - Commit messages: - 8287155: Additional make typos Changes: https://git.openjdk.java.net/jdk/pull/8837/files

Re: RFR: 8286262: Windows: Cleanup deprecation warning suppression

2022-05-23 Thread David Holmes
On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2)