-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Updating Number.Formatting to properly print -0 #19775
Conversation
FYI. @danmosemsft, @jkotas This covers part of
|
This fixes This impacts 'R', as well as the other formats (such as 'G'). If we want to restrict this to just 'R', that will be a slightly more involved change. |
Looks like -- Looking at CoreFX there doesn't appear to be existing code coverage for "R" or some of the special-cases (tests are still running locally to confirm I didn't just miss them). I'll work on getting those cases covered. |
src/pal/src/cruntime/math.cpp
Outdated
x Double-precision floating-point value | ||
|
||
--*/ | ||
int __cdecl PAL_signbit(double x) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had to add PAL_signbit
.... Clang complains about importing fp.h
and using FPDOUBLE
to get the sign-bit, because the header also declares a static function which is unused in grisu3.cpp
Rather than fix the header or compilation flags, I opted to just use signbit
, since it is the standard library function to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm, looks like that won't work on all platforms, due to it being a #define
sometimes (or I missed something)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You may need to add signbit to src/pal/src/include/pal/palinternal.h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding it to palinternal.h
doesn't work in this case, because it is a macro in the math.h
file.
I had to do what the other "macro" PAL redefinitions are doing (like isfinite
and isnan
), which is to define a new function (_signbit
) which calls the macro, and then use the new function everywhere.
For the existing ones, the new function name was selected to match the MSVC function name (_finite
, _isnan
, etc). Since there is no _signbit
function for MSVC (just signbit
), I had to (for MSVC) also do #define signbit _signbit
.
Will go through the various CoreFX failures and make sure they are all expected. |
At least one of the failures is due to a bad change (specifically relating to integers). The break is in We are currently bypassing rounding (for |
|
Rebased to try and get jobs to run, most of them didn't kick off last time. CoreFX side change is here: dotnet/corefx#32109 |
This comment seems out of date now. I don't see you updating the number.h file. Refers to: src/System.Private.CoreLib/shared/System/Number.NumberBuffer.cs:16 in 5f66c17. [](commit_id = 5f66c17, deletion_comment = False) |
@@ -488,6 +490,7 @@ private static string FormatSingle(ref ValueStringBuilder sb, float value, ReadO | |||
char fmt = ParseFormatSpecifier(format, out int digits); | |||
int precision = FloatPrecision; | |||
NumberBuffer number = default; | |||
number.kind = NumberBufferKind.Double; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make more sense for NumberBufferKind.Double
to be renamed to NumberBufferKind.FloatingPoint
or similar? It feels odd to use Double
when we are working with float
/Single
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly, but I would like to do that as a follow-up PR.
Currently we use DoubleToNumber
for both single
and double
.... We should probably either rename that as well, or add an explicit code-path for SingleToNumber
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are introducing the enum
in this PR. Why not give it a good name from the start?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because, until the the methods are split to handle Single
explicitly, it is actually a NumberBuffer
which contains a Double
(Single
is upcast in order to make the call) and so the name is more accurate as-is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, got it. That makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, added comments clarifying the expected offset of each field as well. |
Turns out the Windows x86 implementation was using a custom implementation written in assembly (that still used the x87 FPU stack). |
Seems reasonable but this is not my area. It would be good for @jkotas to OK it. |
The invalidated CoreFX tests need to be disabled to make the CI green. |
@jkotas, is there a file tracking those tests in CoreCLR, or do they need to be disabled in CoreFX directly? |
test Ubuntu x64 Checked jitstress1 test Windows_NT x64 Checked jitstress1 test Windows_NT x86 Checked jitstress1 |
Fixed the name of the CoreFX tests in the json file. |
@fiigii, the |
@jkotas, any other feedback? If not, this should be good to merge, the only failures are in the JitStress1 and JitStress2 jobs and are unrelated to the PR. |
@tannergooding I will look into this failure tomorrow, thanks. |
This resolves https://github.com/dotnet/coreclr/issues/10290