Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test: Add f64.{add,sub} off by one unit tests #786

Merged
merged 1 commit into from
Apr 22, 2021
Merged

Conversation

chfast
Copy link
Collaborator

@chfast chfast commented Apr 16, 2021

The i386 x87 FPU performs all arithmetic with 80-bit extended precision
by default and in the end rounds it to the required type. This causes
issues for f64 types because results may be different than when doing
computation with 64-bit precision. f32 is not affected.
These tests presents examples of results which are different in such
case.

@codecov
Copy link

codecov bot commented Apr 16, 2021

Codecov Report

Merging #786 (c9525d2) into master (ece653a) will increase coverage by 0.01%.
The diff coverage is 96.29%.

@@            Coverage Diff             @@
##           master     #786      +/-   ##
==========================================
+ Coverage   99.22%   99.23%   +0.01%     
==========================================
  Files          79       79              
  Lines       12060    12394     +334     
==========================================
+ Hits        11966    12299     +333     
- Misses         94       95       +1     
Flag Coverage Δ
rust 99.90% <ø> (+0.03%) ⬆️
spectests 90.54% <ø> (ø)
unittests 99.16% <96.29%> (-0.01%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
test/unittests/execute_floating_point_test.cpp 99.55% <96.29%> (-0.14%) ⬇️
bindings/rust/src/lib.rs 99.90% <0.00%> (+0.03%) ⬆️

@chfast chfast requested review from gumb0 and axic April 16, 2021 12:29
// The i386 x87 FPU performs all arithmetic with 80-bit extended precision by default
// and in the end rounds it to the required type. This causes issues for f64 types
// because results may be different than when doing computation with 64-bit precision.
// f32 is not affected.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is f32 not affected?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some sources says that float has too low precision to observe different results. This is confirmed by testfloat tests.

auto instance = instantiate(parse(wasm));

constexpr auto a = 0x1.0008000008000p60;
constexpr auto b = 0x1.0000000081fffp07;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you know the easy way to do this, maybe it would be helpful to comment with "de-normalized" exponent 60 value of this.

I mean, as I understand, it's something like this:

Suggested change
constexpr auto b = 0x1.0000000081fffp07;
constexpr auto a = 0x1.0008000008000p60;
constexpr auto b = 0x1.0000000081fffp07; // 0x0.00000000000008...p60;

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really know what exactly is going on here. Maybe if we convert this also to long double we may see what's going on.

The i386 x87 FPU performs all arithmetic with 80-bit extended precision
by default and in the end rounds it to the required type. This causes
issues for f64 types because results may be different than when doing
computation with 64-bit precision. f32 is not affected.
These tests presents examples of results which are different in such
case.
@chfast chfast merged commit 2ea01bc into master Apr 22, 2021
@chfast chfast deleted the x87_fpu_tests branch April 22, 2021 13:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants