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?










-3















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










share|improve this question



















  • 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















-3















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










share|improve this question



















  • 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













-3












-3








-3


1






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










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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












  • 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







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












1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer

























  • 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 after if(isAuto) inside

    – Tzalumen
    Mar 7 at 21:21










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









0














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.






share|improve this answer

























  • 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 after if(isAuto) inside

    – Tzalumen
    Mar 7 at 21:21















0














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.






share|improve this answer

























  • 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 after if(isAuto) inside

    – Tzalumen
    Mar 7 at 21:21













0












0








0







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.






share|improve this answer















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.







share|improve this answer














share|improve this answer



share|improve this answer








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 after if(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











  • 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 after if(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



















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%2f55050962%2fwhy-does-this-if-else-statement-appear-to-be-optimized-away%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

Can't initialize raids on a new ASUS Prime B360M-A motherboard2019 Community Moderator ElectionSimilar to RAID config yet more like mirroring solution?Can't get motherboard serial numberWhy does the BIOS entry point start with a WBINVD instruction?UEFI performance Asus Maximus V Extreme

Identity Server 4 is not redirecting to Angular app after login2019 Community Moderator ElectionIdentity Server 4 and dockerIdentityserver implicit flow unauthorized_clientIdentityServer Hybrid Flow - Access Token is null after user successful loginIdentity Server to MVC client : Page Redirect After loginLogin with Steam OpenId(oidc-client-js)Identity Server 4+.NET Core 2.0 + IdentityIdentityServer4 post-login redirect not working in Edge browserCall to IdentityServer4 generates System.NullReferenceException: Object reference not set to an instance of an objectIdentityServer4 without HTTPS not workingHow to get Authorization code from identity server without login form

2005 Ahvaz unrest Contents Background Causes Casualties Aftermath See also References Navigation menue"At Least 10 Are Killed by Bombs in Iran""Iran"Archived"Arab-Iranians in Iran to make April 15 'Day of Fury'"State of Mind, State of Order: Reactions to Ethnic Unrest in the Islamic Republic of Iran.10.1111/j.1754-9469.2008.00028.x"Iran hangs Arab separatists"Iran Overview from ArchivedConstitution of the Islamic Republic of Iran"Tehran puzzled by forged 'riots' letter""Iran and its minorities: Down in the second class""Iran: Handling Of Ahvaz Unrest Could End With Televised Confessions""Bombings Rock Iran Ahead of Election""Five die in Iran ethnic clashes""Iran: Need for restraint as anniversary of unrest in Khuzestan approaches"Archived"Iranian Sunni protesters killed in clashes with security forces"Archived