Perfectly fine division throws floating point exception












1















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:



enter image description here



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?










share|improve this question























  • 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 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
















1















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:



enter image description here



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?










share|improve this question























  • 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 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














1












1








1








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:



enter image description here



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?










share|improve this question














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:



enter image description here



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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 30 '18 at 23:56









BramBram

2,6562250




2,6562250













  • 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 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



















  • 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 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

















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












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
});


}
});














draft saved

draft discarded


















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
















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas