On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an implemen
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an implemen
On Sat, 1 Apr 2023 18:08:44 GMT, Joe Darcy wrote:
> This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
> JDK-8302801 was that it neglected (mea culpa) to include a Java
> implementation of IEEEremainder before the FDLIBM C implementation was
> deleted. Such an implemen
This PR is a redo of JDK-8302801: Remove fdlibm C sources. The problem with
JDK-8302801 was that it neglected (mea culpa) to include a Java implementation
of IEEEremainder before the FDLIBM C implementation was deleted. Such an
implementation has been successfully provided under JDK-8304028: Por
On Thu, 30 Mar 2023 21:05:40 GMT, Joshua Cao wrote:
> Builds successfully with GCC 7
>
>
> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHA
On Fri, 31 Mar 2023 21:27:08 GMT, Joshua Cao wrote:
>> Builds successfully with GCC 7
>>
>>
>> gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15)
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There is NO
>> warranty; not even for
> A previous argument against link time optimization support that we have for
> gcc is that it was extremely slow. After some checks it turns out we are
> passing rather inefficient flags to gcc in optimized builds. Changing these
> flags to run the linker optimizations in parallel and passing a
On Fri, 24 Mar 2023 17:12:26 GMT, Julian Waters wrote:
> A previous argument against link time optimization support that we have for
> gcc is that it was extremely slow. After some checks it turns out we are
> passing rather inefficient flags to gcc in optimized builds. Changing these
> flags
On Sun, 2 Apr 2023 07:24:24 GMT, Alan Bateman wrote:
> I assume at least tier1-4 has been run, in which case this looks good (same
> as previous PR).
Right; tier 1 - 4 job was successful other than an unrelated time-out.
Previously, with the initial removal attempt there were many failures in
