On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
This PR intends to remove the legacy `COMPAT` locale data from the JDK. The
`COMPAT` locale data was introduced for applications' migratory purposes
transitioning to `CLDR`. It is becoming a technical debt and now is the time to
remove it (we've been emitting a warning at JVM startup since
Vote: Yes
On 2/19/24 6:40 PM, Stuart Marks wrote:
I hereby nominate Viktor Klang [6] to Membership in the Core Libraries
Group [4].
On Thu, 22 Feb 2024 23:43:41 GMT, Brent Christian wrote:
>> Thanks for finding my misspelling, djelinski.
>
> The use of "(un)successful(ly)" in relation to `Reference.enqueue()` is quite
> deliberate (and builds on the previous wording, "successful").
>
> The intention was to use it
On Fri, 22 Sep 2023 15:33:11 GMT, Raffaello Giulietti
wrote:
>> Joe Darcy 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 request contains six additional
On Fri, 22 Sep 2023 21:32:26 GMT, Joe Darcy wrote:
> For FDLIBM tan, the stated error in the Math.tan spec is 1 ulp and the FDLIBM
> sources say tan is "nearly rounded," which could reasonably be interpreted as
> meaning within 1 ulp. However, the reported error by the paper is 1.02 ulps.
>
>
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
> details the inputs with generate the worst-case
On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote:
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
>
The new test JmodExcludedFiles.java checks that no debug symbol files are
contained in the jmod files. It does not take into account that with configure
option --with-external-symbols-in-bundles=public we want to have stripped pdb
files, also in jmods, to get native callstacks with line number.
On Fri, 22 Sep 2023 15:48:26 GMT, Raffaello Giulietti
wrote:
> Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result
> here. I don't know why the paper says otherwise. Perhaps OpenLibm is not
> exactly fdlibm.
I've looked a bit over the OpenLibm changelog. They've added a
On Fri, 23 Feb 2024 17:29:18 GMT, Justin Lu wrote:
>> Please review this PR which handles an edge case pattern bug with
>> ChoiceFormat.
>>
>>
>> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
>> "0.0#foo|1.0#bar|1.0#"
>> d.format(1) // unexpectedly returns ""
>>
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy wrote:
> Widen acceptable error bound of Math.tan to accommodate the worst-case
> observed error which is slightly outside of the allowable range.
This pull request has now been integrated.
Changeset: 63f6a563
Author:Joe Darcy
URL:
> Please review this PR which handles an edge case pattern bug with
> ChoiceFormat.
>
>
> var d = new ChoiceFormat("0#foo|1#bar|baz|") // creates cFmt equivalent to
> "0.0#foo|1.0#bar|1.0#"
> d.format(1) // unexpectedly returns ""
>
>
> Not only does this lead to faulty formatting results,
On Fri, 23 Feb 2024 00:21:57 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> revert enum change
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 342:
>
>> 340: } else {
>>
On Fri, 23 Feb 2024 16:23:43 GMT, Magnus Ihse Bursie wrote:
> The idea of setting up general "toolchains" in the native build was good, but
> it turned out that we really only need a single toolchain, with a single
> twist: if it should use CC or CPP to link. This is better described by a
>
The idea of setting up general "toolchains" in the native build was good, but
it turned out that we really only need a single toolchain, with a single twist:
if it should use CC or CPP to link. This is better described by a specific
argument to SetupNativeCompilation, LANG := C++ or LANG := C
On Thu, 22 Feb 2024 11:38:19 GMT, Christoph Langer wrote:
> As for the test, I had a closer look now and I find it hard to separate
> testing of [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) from
> [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). Furthermore, most
> of
On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy wrote:
> Widen acceptable error bound of Math.tan to accommodate the worst-case
> observed error which is slightly outside of the allowable range.
Marked as reviewed by rgiulietti (Reviewer).
Checked with high precision math. The bound reported on
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
On Thu, 22 Feb 2024 16:01:19 GMT, Matthias Baesken wrote:
>> Currently assertEquals has in the failure case sometimes confusing output
>> like :
>>
>> java.lang.RuntimeException: VM output should contain exactly one RTM locking
>> statistics entry for method
>>
22 matches
Mail list logo
