Perfectly fine division throws floating point exception
I have a mystery floating point exception.
I catch it by doing:
feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
Then the second division (last line) in this code:
const float dx = other.px[ j ] - curx;
const float dy = other.py[ j ] - cury;
const float dsqr = dx*dx + dy*dy;
ASSERTM( dsqr > 0.0f, "dx %f dy %f dsqr %f", dx, dy, dsqr );
const float dist = sqrtf( dsqr );
ASSERTM( dist > 0.0f, "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
LOGI( "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
const float dirx = dx / dist;
const float diry = dy / dist;
Throws a SIGFPE as follows:
The divisor (printed out in console, and also printed by gdb) is 1.0839119 and numerator is -1.05979919 so I don't see what is wrong with that.
For extra weirdness:
- Does not happen in -O0 debug build.
- Does not happen if I run the app through valgrind
Compiler:
$ clang -v
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
And compiler options:
clang++ -DXWIN -DLANDSCAPE -DUSECOREPROFILE -Dlinux -D_POSIX_C_SOURCE=199309L -D_DEFAULT_SOURCE -DAPPVER=1.00 -DLOGTAG=minimal -I/home/bram/src/stb/ -I/home/bram/include -I/public -I/home/bram/src/dutch-blunt/src -I/home/bram/apps/GBase/src -IPI -I/home/bram/src/ThreadTracer `/home/bram/bin/sdl2-config --cflags` -g -Wall -Wshadow -Wno-conversion -Wno-missing-braces -Wno-old-style-cast -Wno-unknown-pragmas -MMD -MP -O2 -std=c++11 -c -o PI/stars.o PI/stars.cpp
Why is this FPE happening? The only reason I could think of, is that even though it is a scalar division, clang generates a SIMD division. What if the other lanes in the XMM register contain zero denominators? Do SIMD divisions generate FPEs if any of the lanes divides by zero? If so, how can I ever trap FPEs?
floating-point clang floating-point-exceptions
add a comment |
I have a mystery floating point exception.
I catch it by doing:
feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
Then the second division (last line) in this code:
const float dx = other.px[ j ] - curx;
const float dy = other.py[ j ] - cury;
const float dsqr = dx*dx + dy*dy;
ASSERTM( dsqr > 0.0f, "dx %f dy %f dsqr %f", dx, dy, dsqr );
const float dist = sqrtf( dsqr );
ASSERTM( dist > 0.0f, "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
LOGI( "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
const float dirx = dx / dist;
const float diry = dy / dist;
Throws a SIGFPE as follows:
The divisor (printed out in console, and also printed by gdb) is 1.0839119 and numerator is -1.05979919 so I don't see what is wrong with that.
For extra weirdness:
- Does not happen in -O0 debug build.
- Does not happen if I run the app through valgrind
Compiler:
$ clang -v
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
And compiler options:
clang++ -DXWIN -DLANDSCAPE -DUSECOREPROFILE -Dlinux -D_POSIX_C_SOURCE=199309L -D_DEFAULT_SOURCE -DAPPVER=1.00 -DLOGTAG=minimal -I/home/bram/src/stb/ -I/home/bram/include -I/public -I/home/bram/src/dutch-blunt/src -I/home/bram/apps/GBase/src -IPI -I/home/bram/src/ThreadTracer `/home/bram/bin/sdl2-config --cflags` -g -Wall -Wshadow -Wno-conversion -Wno-missing-braces -Wno-old-style-cast -Wno-unknown-pragmas -MMD -MP -O2 -std=c++11 -c -o PI/stars.o PI/stars.cpp
Why is this FPE happening? The only reason I could think of, is that even though it is a scalar division, clang generates a SIMD division. What if the other lanes in the XMM register contain zero denominators? Do SIMD divisions generate FPEs if any of the lanes divides by zero? If so, how can I ever trap FPEs?
floating-point clang floating-point-exceptions
Bram, I would say you were correct, the divps doc saysPerforms a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand).
This may be a compiler bug.
– paxdiablo
Dec 31 '18 at 0:05
1
I would think that, if it were going to use simd for two divisions, it would ensure the others (forced ones) would be valid. Maybe they never tested it with exceptions enabled. I'd suggest raising this on the clang bug site and see what they say.
– paxdiablo
Dec 31 '18 at 0:08
1
gcc
andclang
basically don't support non-default floating-point environments. You can try-fsanitize=float-divide-by-zero
instead.
– Tavian Barnes
Dec 31 '18 at 0:10
add a comment |
I have a mystery floating point exception.
I catch it by doing:
feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
Then the second division (last line) in this code:
const float dx = other.px[ j ] - curx;
const float dy = other.py[ j ] - cury;
const float dsqr = dx*dx + dy*dy;
ASSERTM( dsqr > 0.0f, "dx %f dy %f dsqr %f", dx, dy, dsqr );
const float dist = sqrtf( dsqr );
ASSERTM( dist > 0.0f, "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
LOGI( "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
const float dirx = dx / dist;
const float diry = dy / dist;
Throws a SIGFPE as follows:
The divisor (printed out in console, and also printed by gdb) is 1.0839119 and numerator is -1.05979919 so I don't see what is wrong with that.
For extra weirdness:
- Does not happen in -O0 debug build.
- Does not happen if I run the app through valgrind
Compiler:
$ clang -v
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
And compiler options:
clang++ -DXWIN -DLANDSCAPE -DUSECOREPROFILE -Dlinux -D_POSIX_C_SOURCE=199309L -D_DEFAULT_SOURCE -DAPPVER=1.00 -DLOGTAG=minimal -I/home/bram/src/stb/ -I/home/bram/include -I/public -I/home/bram/src/dutch-blunt/src -I/home/bram/apps/GBase/src -IPI -I/home/bram/src/ThreadTracer `/home/bram/bin/sdl2-config --cflags` -g -Wall -Wshadow -Wno-conversion -Wno-missing-braces -Wno-old-style-cast -Wno-unknown-pragmas -MMD -MP -O2 -std=c++11 -c -o PI/stars.o PI/stars.cpp
Why is this FPE happening? The only reason I could think of, is that even though it is a scalar division, clang generates a SIMD division. What if the other lanes in the XMM register contain zero denominators? Do SIMD divisions generate FPEs if any of the lanes divides by zero? If so, how can I ever trap FPEs?
floating-point clang floating-point-exceptions
I have a mystery floating point exception.
I catch it by doing:
feenableexcept( FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
Then the second division (last line) in this code:
const float dx = other.px[ j ] - curx;
const float dy = other.py[ j ] - cury;
const float dsqr = dx*dx + dy*dy;
ASSERTM( dsqr > 0.0f, "dx %f dy %f dsqr %f", dx, dy, dsqr );
const float dist = sqrtf( dsqr );
ASSERTM( dist > 0.0f, "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
LOGI( "dx %f dy %f dsqr %f dist %f", dx, dy, dsqr, dist );
const float dirx = dx / dist;
const float diry = dy / dist;
Throws a SIGFPE as follows:
The divisor (printed out in console, and also printed by gdb) is 1.0839119 and numerator is -1.05979919 so I don't see what is wrong with that.
For extra weirdness:
- Does not happen in -O0 debug build.
- Does not happen if I run the app through valgrind
Compiler:
$ clang -v
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
And compiler options:
clang++ -DXWIN -DLANDSCAPE -DUSECOREPROFILE -Dlinux -D_POSIX_C_SOURCE=199309L -D_DEFAULT_SOURCE -DAPPVER=1.00 -DLOGTAG=minimal -I/home/bram/src/stb/ -I/home/bram/include -I/public -I/home/bram/src/dutch-blunt/src -I/home/bram/apps/GBase/src -IPI -I/home/bram/src/ThreadTracer `/home/bram/bin/sdl2-config --cflags` -g -Wall -Wshadow -Wno-conversion -Wno-missing-braces -Wno-old-style-cast -Wno-unknown-pragmas -MMD -MP -O2 -std=c++11 -c -o PI/stars.o PI/stars.cpp
Why is this FPE happening? The only reason I could think of, is that even though it is a scalar division, clang generates a SIMD division. What if the other lanes in the XMM register contain zero denominators? Do SIMD divisions generate FPEs if any of the lanes divides by zero? If so, how can I ever trap FPEs?
floating-point clang floating-point-exceptions
floating-point clang floating-point-exceptions
asked Dec 30 '18 at 23:56
BramBram
2,6562250
2,6562250
Bram, I would say you were correct, the divps doc saysPerforms a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand).
This may be a compiler bug.
– paxdiablo
Dec 31 '18 at 0:05
1
I would think that, if it were going to use simd for two divisions, it would ensure the others (forced ones) would be valid. Maybe they never tested it with exceptions enabled. I'd suggest raising this on the clang bug site and see what they say.
– paxdiablo
Dec 31 '18 at 0:08
1
gcc
andclang
basically don't support non-default floating-point environments. You can try-fsanitize=float-divide-by-zero
instead.
– Tavian Barnes
Dec 31 '18 at 0:10
add a comment |
Bram, I would say you were correct, the divps doc saysPerforms a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand).
This may be a compiler bug.
– paxdiablo
Dec 31 '18 at 0:05
1
I would think that, if it were going to use simd for two divisions, it would ensure the others (forced ones) would be valid. Maybe they never tested it with exceptions enabled. I'd suggest raising this on the clang bug site and see what they say.
– paxdiablo
Dec 31 '18 at 0:08
1
gcc
andclang
basically don't support non-default floating-point environments. You can try-fsanitize=float-divide-by-zero
instead.
– Tavian Barnes
Dec 31 '18 at 0:10
Bram, I would say you were correct, the divps doc says
Performs a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand).
This may be a compiler bug.– paxdiablo
Dec 31 '18 at 0:05
Bram, I would say you were correct, the divps doc says
Performs a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand).
This may be a compiler bug.– paxdiablo
Dec 31 '18 at 0:05
1
1
I would think that, if it were going to use simd for two divisions, it would ensure the others (forced ones) would be valid. Maybe they never tested it with exceptions enabled. I'd suggest raising this on the clang bug site and see what they say.
– paxdiablo
Dec 31 '18 at 0:08
I would think that, if it were going to use simd for two divisions, it would ensure the others (forced ones) would be valid. Maybe they never tested it with exceptions enabled. I'd suggest raising this on the clang bug site and see what they say.
– paxdiablo
Dec 31 '18 at 0:08
1
1
gcc
and clang
basically don't support non-default floating-point environments. You can try -fsanitize=float-divide-by-zero
instead.– Tavian Barnes
Dec 31 '18 at 0:10
gcc
and clang
basically don't support non-default floating-point environments. You can try -fsanitize=float-divide-by-zero
instead.– Tavian Barnes
Dec 31 '18 at 0:10
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53982412%2fperfectly-fine-division-throws-floating-point-exception%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53982412%2fperfectly-fine-division-throws-floating-point-exception%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Bram, I would say you were correct, the divps doc says
Performs a SIMD divide of the four, eight or sixteen packed single-precision floating-point values in the first source operand (the second operand) by the four, eight or sixteen packed single-precision floating-point values in the second source operand (the third operand).
This may be a compiler bug.– paxdiablo
Dec 31 '18 at 0:05
1
I would think that, if it were going to use simd for two divisions, it would ensure the others (forced ones) would be valid. Maybe they never tested it with exceptions enabled. I'd suggest raising this on the clang bug site and see what they say.
– paxdiablo
Dec 31 '18 at 0:08
1
gcc
andclang
basically don't support non-default floating-point environments. You can try-fsanitize=float-divide-by-zero
instead.– Tavian Barnes
Dec 31 '18 at 0:10