Re: Inconsistent revision control
Thread archived at https://mail.openjdk.org/pipermail/build-dev/2023-June/039957.html -Joe On 6/26/2023 6:03 PM, Alan Snyder wrote: I’m deducing the existence of a message from Erik that I did not receive. Perhaps someone can repost it?
Re: Inconsistent revision control
And anyone is free to use the standard set of tools, which is know to work and used daily by dozens to hundreds of developers. -Joe On 6/26/2023 3:24 PM, David Holmes wrote: On 27/06/2023 8:04 am, Alan Snyder wrote: An incremental clone is a sync, like an incremental backup. Erik responded to a different question. I’ve gotten no closer to figuring out this problem. Erik responded to exactly your question. Feel free to be helpful, if you can. I don’t think it is helpful to nitpick my words. When your words do not make it clear what exactly it is you are reporting then they need to be clarified. "clone" is a git operation not a build one. David On Jun 26, 2023, at 2:46 PM, David Holmes wrote: On 27/06/2023 7:40 am, Alan Snyder wrote: No, I meant incremental clone. What is an incremental clone? After updating the directory, I tried to do an incremental build and got the strange message. So you did mean "incremental build". After that, I tried doing a full build, reconfiguring, etc., but nothing helped. Now that you know that a build tool is involved, can you help me figure out what the problem is? I think Erik already addressed that. David On Jun 26, 2023, at 2:32 PM, David Holmes wrote: On 26/06/2023 10:55 pm, Alan Snyder wrote: It would be very unlikely for CCC to fail to correctly clone the directory. It would be helpful to know what the build tool is complaining about with that message. Wasn't apparent any build tool was involved. You stated: After an incremental clone of the directory tree, I get mysterious messages like this: I presume you actually meant "incremental build". David On Jun 25, 2023, at 10:04 PM, David Holmes wrote: On 24/06/2023 12:28 pm, Alan Snyder wrote: I have been trying to use Carbon Copy Cloner to make a copy of an active jdk repo on another macOS machine for the purpose of running tests. The initial clone is fine. After an incremental clone of the directory tree, I get mysterious messages like this: Inconsistent revision control: 17-24-55/ is missing .git directory What is this about? Is there an easy way to fix this problem? This isn't really a build issue. I can only suggest that you check that the copy you made actually copied across all hidden directories, e.g. .git, as well. Cheers, David
Re: RFR: 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic [v7]
PS And additional expressions could be crashed to rule out
flush-to-zero, treating all subnormals and zero, and other non-compliant
modes of operation.
-Joe
On 10/20/2022 1:05 PM, Joseph D. Darcy wrote:
On 10/20/2022 10:43 AM, Andrew Haley wrote:
On Wed, 12 Oct 2022 17:00:15 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 and restore the floating-point control word
around System.loadLibrary(). This isn't perfect, because some
shared library might load another shared library at runtime, but
it's a lot better than what we do now.
However, this fix is not complete. `dlopen()` is called from many
places in the JDK. I guess the best thing to do is find and wrap
them all. I'd like to hear people's opinions.
Andrew Haley has updated the pull request incrementally with one
additional commit since the last revision:
8295159: DSO created with -ffast-math breaks Java floating-point
arithmetic
So here's a thought:
Reading and writing floating-point control flags can be expensive
because they're serializing operations. However, we can discover
whether the processor has been put into an "odd" rounding mode with
just a few floating-point instructions, so we can do:
if (epsilon + epsilon == 0) {
rtn = fesetenv(_fenv)
}
Assuming the rounding mode could be one of the four classic rounding
modes (to nearest even, to +infinity, to -infinity, to zero), two
calculations are needed to determine if the mode is set to nearest
even, as required by the JVM.
Candidate calculations are
1.0 + ROUND_THRESH == 1.0
-1.0 - ROUND_THRESH == -1.0
with the decoding
false false => to nearest
false true => to positive infinity
true false => to negative infinity
true true => to zero
For double, the double rounding threshold is 2^–53 + 2^–105 ≈
1.1102230246251568e –16. An analogous constant can be derived for
float, if desired
HTH,
-Joe
Re: RFR: 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic [v7]
On 10/20/2022 10:43 AM, Andrew Haley wrote:
On Wed, 12 Oct 2022 17:00:15 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 and restore the floating-point control word around
System.loadLibrary(). This isn't perfect, because some shared library might
load another shared library at runtime, but it's a lot better than what we do
now.
However, this fix is not complete. `dlopen()` is called from many places in the
JDK. I guess the best thing to do is find and wrap them all. I'd like to hear
people's opinions.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
8295159: DSO created with -ffast-math breaks Java floating-point arithmetic
So here's a thought:
Reading and writing floating-point control flags can be expensive because they're
serializing operations. However, we can discover whether the processor has been put into
an "odd" rounding mode with just a few floating-point instructions, so we can
do:
if (epsilon + epsilon == 0) {
rtn = fesetenv(_fenv)
}
Assuming the rounding mode could be one of the four classic rounding
modes (to nearest even, to +infinity, to -infinity, to zero), two
calculations are needed to determine if the mode is set to nearest even,
as required by the JVM.
Candidate calculations are
1.0 + ROUND_THRESH == 1.0
-1.0 - ROUND_THRESH == -1.0
with the decoding
false false => to nearest
false true => to positive infinity
true false => to negative infinity
true true => to zero
For double, the double rounding threshold is 2^–53 + 2^–105 ≈
1.1102230246251568e –16. An analogous constant can be derived for float,
if desired
HTH,
-Joe
