Why does this if/else statement appear to be optimized away?2019 Community Moderator ElectionWhy can't variables be declared in a switch statement?Why use apparently meaningless do-while and if-else statements in macros?else statement is seemingly ignoredWhy doesn't GCC optimize a*a*a*a*a*a to (a*a*a)*(a*a*a)?Why does changing 0.1f to 0 slow down performance by 10x?break condition to OR and AND operators in an IF StatementWhy does Visual Studio Release build break on non-executing code lineif..else statement in the c++ standardReplacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsWhy does this if conditional with string.length() evaluate inconsistently?
How to balance a monster modification (zombie)?
Isn't the word "experience" wrongly used in this context?
I got the following comment from a reputed math journal. What does it mean?
Single word to change groups
Gauss brackets with double vertical lines
If I cast the Enlarge/Reduce spell on an arrow, what weapon could it count as?
How old is Nick Fury?
What will the Frenchman say?
PTIJ: Which Dr. Seuss books should one obtain?
Do I need to convey a moral for each of my blog post?
How to test the sharpness of a knife?
Would mining huge amounts of resources on the Moon change its orbit?
is this saw blade faulty?
How can an organ that provides biological immortality be unable to regenerate?
What is the tangent at a sharp point on a curve?
How to find the largest number(s) in a list of elements, possibly non-unique?
Can other pieces capture a threatening piece and prevent a checkmate?
Does fire aspect on a sword, destroy mob drops?
What are the consequences of changing the number of hours in a day?
Nested Dynamic SOQL Query
label a part of commutative diagram
The English Debate
PTIJ: Why do we make a Lulav holder?
Should I be concerned about student access to a test bank?
Why does this if/else statement appear to be optimized away?
2019 Community Moderator ElectionWhy can't variables be declared in a switch statement?Why use apparently meaningless do-while and if-else statements in macros?else statement is seemingly ignoredWhy doesn't GCC optimize a*a*a*a*a*a to (a*a*a)*(a*a*a)?Why does changing 0.1f to 0 slow down performance by 10x?break condition to OR and AND operators in an IF StatementWhy does Visual Studio Release build break on non-executing code lineif..else statement in the c++ standardReplacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsWhy does this if conditional with string.length() evaluate inconsistently?
This is the code in question:
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
long int val = value;
if (evtID == stickXInputID
When I compile a debug build, this runs perfectly. When I compile a release build, it does not work. When I attach the visual studio debugger to the release version, I can break on the first if statement and on the closing brace of the function, but I cannot hit a break point anywhere else, and neither stickXpct or stickYpct are ever being assigned anything, although in the debugger I can see that "value" has a valid value, and "evtID" DOES equal one of inputIDs.
In conclusion, it looks to me like, in the release version of the code only, both the first "if" statement and the first "else if" statement only evaluate to false, even when one of them should evaluate to true. Does anyone know what is going on here? because I don't.
Thanks so much,
Farley
c++ visual-studio-2017 compiler-optimization
|
show 5 more comments
This is the code in question:
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
long int val = value;
if (evtID == stickXInputID
When I compile a debug build, this runs perfectly. When I compile a release build, it does not work. When I attach the visual studio debugger to the release version, I can break on the first if statement and on the closing brace of the function, but I cannot hit a break point anywhere else, and neither stickXpct or stickYpct are ever being assigned anything, although in the debugger I can see that "value" has a valid value, and "evtID" DOES equal one of inputIDs.
In conclusion, it looks to me like, in the release version of the code only, both the first "if" statement and the first "else if" statement only evaluate to false, even when one of them should evaluate to true. Does anyone know what is going on here? because I don't.
Thanks so much,
Farley
c++ visual-studio-2017 compiler-optimization
3
your wild casts are a bit suspicuous, I am not sure at all, but UB due to one of the casts could be a reason
– user463035818
Mar 7 at 19:01
long int val = *reinterpret_cast<long int *>(&value);
invokes undefined behavior
– UnholySheep
Mar 7 at 19:02
1
You need to provide a Minimal, Complete, and Verifiable example. As is, the code refers to variables (class members) that could be anything - and, more importantly, their types and values could be relevant to the effect you're seeing. Thatreinterpret_cast
is highly suspicious though. The need for all the other type conversions are potentially danger signs. I'd bet there is some undefined or unspecified behaviour in there somewhere - in which case, the compiler is allowed to do strange things.
– Peter
Mar 7 at 19:04
There is not enough code to give conclusive answer, but it looks like UB somewhere. Could be your liberal casts, could be something else.
– SergeyA
Mar 7 at 19:06
By the way,long int val = *reinterpret_cast<long int *>(&value);
is completely unnecessary -long int val = value
will be perfect.
– SergeyA
Mar 7 at 19:08
|
show 5 more comments
This is the code in question:
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
long int val = value;
if (evtID == stickXInputID
When I compile a debug build, this runs perfectly. When I compile a release build, it does not work. When I attach the visual studio debugger to the release version, I can break on the first if statement and on the closing brace of the function, but I cannot hit a break point anywhere else, and neither stickXpct or stickYpct are ever being assigned anything, although in the debugger I can see that "value" has a valid value, and "evtID" DOES equal one of inputIDs.
In conclusion, it looks to me like, in the release version of the code only, both the first "if" statement and the first "else if" statement only evaluate to false, even when one of them should evaluate to true. Does anyone know what is going on here? because I don't.
Thanks so much,
Farley
c++ visual-studio-2017 compiler-optimization
This is the code in question:
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
long int val = value;
if (evtID == stickXInputID
When I compile a debug build, this runs perfectly. When I compile a release build, it does not work. When I attach the visual studio debugger to the release version, I can break on the first if statement and on the closing brace of the function, but I cannot hit a break point anywhere else, and neither stickXpct or stickYpct are ever being assigned anything, although in the debugger I can see that "value" has a valid value, and "evtID" DOES equal one of inputIDs.
In conclusion, it looks to me like, in the release version of the code only, both the first "if" statement and the first "else if" statement only evaluate to false, even when one of them should evaluate to true. Does anyone know what is going on here? because I don't.
Thanks so much,
Farley
c++ visual-studio-2017 compiler-optimization
c++ visual-studio-2017 compiler-optimization
edited Mar 7 at 19:20
lequinne
asked Mar 7 at 18:56
lequinnelequinne
507
507
3
your wild casts are a bit suspicuous, I am not sure at all, but UB due to one of the casts could be a reason
– user463035818
Mar 7 at 19:01
long int val = *reinterpret_cast<long int *>(&value);
invokes undefined behavior
– UnholySheep
Mar 7 at 19:02
1
You need to provide a Minimal, Complete, and Verifiable example. As is, the code refers to variables (class members) that could be anything - and, more importantly, their types and values could be relevant to the effect you're seeing. Thatreinterpret_cast
is highly suspicious though. The need for all the other type conversions are potentially danger signs. I'd bet there is some undefined or unspecified behaviour in there somewhere - in which case, the compiler is allowed to do strange things.
– Peter
Mar 7 at 19:04
There is not enough code to give conclusive answer, but it looks like UB somewhere. Could be your liberal casts, could be something else.
– SergeyA
Mar 7 at 19:06
By the way,long int val = *reinterpret_cast<long int *>(&value);
is completely unnecessary -long int val = value
will be perfect.
– SergeyA
Mar 7 at 19:08
|
show 5 more comments
3
your wild casts are a bit suspicuous, I am not sure at all, but UB due to one of the casts could be a reason
– user463035818
Mar 7 at 19:01
long int val = *reinterpret_cast<long int *>(&value);
invokes undefined behavior
– UnholySheep
Mar 7 at 19:02
1
You need to provide a Minimal, Complete, and Verifiable example. As is, the code refers to variables (class members) that could be anything - and, more importantly, their types and values could be relevant to the effect you're seeing. Thatreinterpret_cast
is highly suspicious though. The need for all the other type conversions are potentially danger signs. I'd bet there is some undefined or unspecified behaviour in there somewhere - in which case, the compiler is allowed to do strange things.
– Peter
Mar 7 at 19:04
There is not enough code to give conclusive answer, but it looks like UB somewhere. Could be your liberal casts, could be something else.
– SergeyA
Mar 7 at 19:06
By the way,long int val = *reinterpret_cast<long int *>(&value);
is completely unnecessary -long int val = value
will be perfect.
– SergeyA
Mar 7 at 19:08
3
3
your wild casts are a bit suspicuous, I am not sure at all, but UB due to one of the casts could be a reason
– user463035818
Mar 7 at 19:01
your wild casts are a bit suspicuous, I am not sure at all, but UB due to one of the casts could be a reason
– user463035818
Mar 7 at 19:01
long int val = *reinterpret_cast<long int *>(&value);
invokes undefined behavior– UnholySheep
Mar 7 at 19:02
long int val = *reinterpret_cast<long int *>(&value);
invokes undefined behavior– UnholySheep
Mar 7 at 19:02
1
1
You need to provide a Minimal, Complete, and Verifiable example. As is, the code refers to variables (class members) that could be anything - and, more importantly, their types and values could be relevant to the effect you're seeing. That
reinterpret_cast
is highly suspicious though. The need for all the other type conversions are potentially danger signs. I'd bet there is some undefined or unspecified behaviour in there somewhere - in which case, the compiler is allowed to do strange things.– Peter
Mar 7 at 19:04
You need to provide a Minimal, Complete, and Verifiable example. As is, the code refers to variables (class members) that could be anything - and, more importantly, their types and values could be relevant to the effect you're seeing. That
reinterpret_cast
is highly suspicious though. The need for all the other type conversions are potentially danger signs. I'd bet there is some undefined or unspecified behaviour in there somewhere - in which case, the compiler is allowed to do strange things.– Peter
Mar 7 at 19:04
There is not enough code to give conclusive answer, but it looks like UB somewhere. Could be your liberal casts, could be something else.
– SergeyA
Mar 7 at 19:06
There is not enough code to give conclusive answer, but it looks like UB somewhere. Could be your liberal casts, could be something else.
– SergeyA
Mar 7 at 19:06
By the way,
long int val = *reinterpret_cast<long int *>(&value);
is completely unnecessary - long int val = value
will be perfect.– SergeyA
Mar 7 at 19:08
By the way,
long int val = *reinterpret_cast<long int *>(&value);
is completely unnecessary - long int val = value
will be perfect.– SergeyA
Mar 7 at 19:08
|
show 5 more comments
1 Answer
1
active
oldest
votes
Edit: changed answer in response to comments
Try adding volatility
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
That should prevent the compiler from optimizing those branches until you can track down why it wants to optimize those branches away.
I thought of trying that, but I can't use a switch statement because stickXInputID etc. are not constants, they're static member variables (of type DWORD). So I can't use them as switch cases.
– lequinne
Mar 7 at 20:00
Then we're back to stackoverflow.com/help/mcve It's going to be next to impossible to determine the cause with such a limited sample.
– Tzalumen
Mar 7 at 20:03
@lequinne If they are static const DWORD member variables initialized in the class definition then they are constants, and can be used in case labels.
– Oktalist
Mar 7 at 20:32
@Oktalist They're not const, they are returned to this class from somewhere else, during the class constructor. Am currently working on an MCVE, but not sure if I can do it, as the calling code for this function is actually pretty complex... This function is actually a std::function object bound to this class instance, stored in a vector in another object, and called by that object. I'm trying to make a minimal/reproduce-able example, but so far nothing I've tried reproduces the problem, which is not really surprising as I've been using this model for years with no problem.
– lequinne
Mar 7 at 20:52
1
Also please, for the sake of maintainability, put the code afterif(isAuto)
inside
– Tzalumen
Mar 7 at 21:21
|
show 5 more comments
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%2f55050962%2fwhy-does-this-if-else-statement-appear-to-be-optimized-away%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Edit: changed answer in response to comments
Try adding volatility
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
That should prevent the compiler from optimizing those branches until you can track down why it wants to optimize those branches away.
I thought of trying that, but I can't use a switch statement because stickXInputID etc. are not constants, they're static member variables (of type DWORD). So I can't use them as switch cases.
– lequinne
Mar 7 at 20:00
Then we're back to stackoverflow.com/help/mcve It's going to be next to impossible to determine the cause with such a limited sample.
– Tzalumen
Mar 7 at 20:03
@lequinne If they are static const DWORD member variables initialized in the class definition then they are constants, and can be used in case labels.
– Oktalist
Mar 7 at 20:32
@Oktalist They're not const, they are returned to this class from somewhere else, during the class constructor. Am currently working on an MCVE, but not sure if I can do it, as the calling code for this function is actually pretty complex... This function is actually a std::function object bound to this class instance, stored in a vector in another object, and called by that object. I'm trying to make a minimal/reproduce-able example, but so far nothing I've tried reproduces the problem, which is not really surprising as I've been using this model for years with no problem.
– lequinne
Mar 7 at 20:52
1
Also please, for the sake of maintainability, put the code afterif(isAuto)
inside
– Tzalumen
Mar 7 at 21:21
|
show 5 more comments
Edit: changed answer in response to comments
Try adding volatility
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
That should prevent the compiler from optimizing those branches until you can track down why it wants to optimize those branches away.
I thought of trying that, but I can't use a switch statement because stickXInputID etc. are not constants, they're static member variables (of type DWORD). So I can't use them as switch cases.
– lequinne
Mar 7 at 20:00
Then we're back to stackoverflow.com/help/mcve It's going to be next to impossible to determine the cause with such a limited sample.
– Tzalumen
Mar 7 at 20:03
@lequinne If they are static const DWORD member variables initialized in the class definition then they are constants, and can be used in case labels.
– Oktalist
Mar 7 at 20:32
@Oktalist They're not const, they are returned to this class from somewhere else, during the class constructor. Am currently working on an MCVE, but not sure if I can do it, as the calling code for this function is actually pretty complex... This function is actually a std::function object bound to this class instance, stored in a vector in another object, and called by that object. I'm trying to make a minimal/reproduce-able example, but so far nothing I've tried reproduces the problem, which is not really surprising as I've been using this model for years with no problem.
– lequinne
Mar 7 at 20:52
1
Also please, for the sake of maintainability, put the code afterif(isAuto)
inside
– Tzalumen
Mar 7 at 21:21
|
show 5 more comments
Edit: changed answer in response to comments
Try adding volatility
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
That should prevent the compiler from optimizing those branches until you can track down why it wants to optimize those branches away.
Edit: changed answer in response to comments
Try adding volatility
void DeckTug::StickCallback(unsigned long long evtID, DWORD value)
That should prevent the compiler from optimizing those branches until you can track down why it wants to optimize those branches away.
edited Mar 7 at 21:19
answered Mar 7 at 19:50
TzalumenTzalumen
312112
312112
I thought of trying that, but I can't use a switch statement because stickXInputID etc. are not constants, they're static member variables (of type DWORD). So I can't use them as switch cases.
– lequinne
Mar 7 at 20:00
Then we're back to stackoverflow.com/help/mcve It's going to be next to impossible to determine the cause with such a limited sample.
– Tzalumen
Mar 7 at 20:03
@lequinne If they are static const DWORD member variables initialized in the class definition then they are constants, and can be used in case labels.
– Oktalist
Mar 7 at 20:32
@Oktalist They're not const, they are returned to this class from somewhere else, during the class constructor. Am currently working on an MCVE, but not sure if I can do it, as the calling code for this function is actually pretty complex... This function is actually a std::function object bound to this class instance, stored in a vector in another object, and called by that object. I'm trying to make a minimal/reproduce-able example, but so far nothing I've tried reproduces the problem, which is not really surprising as I've been using this model for years with no problem.
– lequinne
Mar 7 at 20:52
1
Also please, for the sake of maintainability, put the code afterif(isAuto)
inside
– Tzalumen
Mar 7 at 21:21
|
show 5 more comments
I thought of trying that, but I can't use a switch statement because stickXInputID etc. are not constants, they're static member variables (of type DWORD). So I can't use them as switch cases.
– lequinne
Mar 7 at 20:00
Then we're back to stackoverflow.com/help/mcve It's going to be next to impossible to determine the cause with such a limited sample.
– Tzalumen
Mar 7 at 20:03
@lequinne If they are static const DWORD member variables initialized in the class definition then they are constants, and can be used in case labels.
– Oktalist
Mar 7 at 20:32
@Oktalist They're not const, they are returned to this class from somewhere else, during the class constructor. Am currently working on an MCVE, but not sure if I can do it, as the calling code for this function is actually pretty complex... This function is actually a std::function object bound to this class instance, stored in a vector in another object, and called by that object. I'm trying to make a minimal/reproduce-able example, but so far nothing I've tried reproduces the problem, which is not really surprising as I've been using this model for years with no problem.
– lequinne
Mar 7 at 20:52
1
Also please, for the sake of maintainability, put the code afterif(isAuto)
inside
– Tzalumen
Mar 7 at 21:21
I thought of trying that, but I can't use a switch statement because stickXInputID etc. are not constants, they're static member variables (of type DWORD). So I can't use them as switch cases.
– lequinne
Mar 7 at 20:00
I thought of trying that, but I can't use a switch statement because stickXInputID etc. are not constants, they're static member variables (of type DWORD). So I can't use them as switch cases.
– lequinne
Mar 7 at 20:00
Then we're back to stackoverflow.com/help/mcve It's going to be next to impossible to determine the cause with such a limited sample.
– Tzalumen
Mar 7 at 20:03
Then we're back to stackoverflow.com/help/mcve It's going to be next to impossible to determine the cause with such a limited sample.
– Tzalumen
Mar 7 at 20:03
@lequinne If they are static const DWORD member variables initialized in the class definition then they are constants, and can be used in case labels.
– Oktalist
Mar 7 at 20:32
@lequinne If they are static const DWORD member variables initialized in the class definition then they are constants, and can be used in case labels.
– Oktalist
Mar 7 at 20:32
@Oktalist They're not const, they are returned to this class from somewhere else, during the class constructor. Am currently working on an MCVE, but not sure if I can do it, as the calling code for this function is actually pretty complex... This function is actually a std::function object bound to this class instance, stored in a vector in another object, and called by that object. I'm trying to make a minimal/reproduce-able example, but so far nothing I've tried reproduces the problem, which is not really surprising as I've been using this model for years with no problem.
– lequinne
Mar 7 at 20:52
@Oktalist They're not const, they are returned to this class from somewhere else, during the class constructor. Am currently working on an MCVE, but not sure if I can do it, as the calling code for this function is actually pretty complex... This function is actually a std::function object bound to this class instance, stored in a vector in another object, and called by that object. I'm trying to make a minimal/reproduce-able example, but so far nothing I've tried reproduces the problem, which is not really surprising as I've been using this model for years with no problem.
– lequinne
Mar 7 at 20:52
1
1
Also please, for the sake of maintainability, put the code after
if(isAuto)
inside – Tzalumen
Mar 7 at 21:21
Also please, for the sake of maintainability, put the code after
if(isAuto)
inside – Tzalumen
Mar 7 at 21:21
|
show 5 more comments
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%2f55050962%2fwhy-does-this-if-else-statement-appear-to-be-optimized-away%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
3
your wild casts are a bit suspicuous, I am not sure at all, but UB due to one of the casts could be a reason
– user463035818
Mar 7 at 19:01
long int val = *reinterpret_cast<long int *>(&value);
invokes undefined behavior– UnholySheep
Mar 7 at 19:02
1
You need to provide a Minimal, Complete, and Verifiable example. As is, the code refers to variables (class members) that could be anything - and, more importantly, their types and values could be relevant to the effect you're seeing. That
reinterpret_cast
is highly suspicious though. The need for all the other type conversions are potentially danger signs. I'd bet there is some undefined or unspecified behaviour in there somewhere - in which case, the compiler is allowed to do strange things.– Peter
Mar 7 at 19:04
There is not enough code to give conclusive answer, but it looks like UB somewhere. Could be your liberal casts, could be something else.
– SergeyA
Mar 7 at 19:06
By the way,
long int val = *reinterpret_cast<long int *>(&value);
is completely unnecessary -long int val = value
will be perfect.– SergeyA
Mar 7 at 19:08