This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Inexecutable statements inside switch case

I have a segment of codes as follows. 'app' is a structure variable.

The code can successfully pass the compiling process and run but contains some inexecutable important commands, which can't be recognized by compiler, e.g.app.bT = TRUE. Besides, there are some disordered jump inside the switch, e.g. jumping from case 1 to case 5 without executing "break" in case 1.

app.bT=FALSE;

do {

switch ( ix )

{

case 0: if ( app.f0< app.fB1 ) app.bT = TRUE; break;

case 1: if (( app.fB1 <= app.f0 )&&( app.f0<= app.fB2 ) ) {if ( app.fC1 > ( ( app.fM1 * app.f0 ) +( app.f_Allowed - app.fM1* app.fB2 ) ) ) app.bT= TRUE; } break;

case 2: if ( app.f0>app.f_Allowed) app.bT = TRUE;

break;

case 3: if (( app.f0 <= app.fB4 ) ) { if ( app.fT > ( ( app.fM2 * app.f0 ) +( app.f_Allowed -app.fM2*app.fB3 ) ) ) app.bT = TRUE; } break;

case 4: if ( app.f0> app.fB4 ) app.bT = TRUE; break; default: break;

}

ix++;

}

while ( ix < 5 && app.bT == FALSE );

I think it's the internal error of C51 since there are few other explanation for this strange problem but I still don't want to believe that's true.
Would you please give me an answer? Thank you for your help.

Parents
  • "are no big difference between statments inside those cases."

    Which is exactly the kind of thing that an optimiser will spot, and then it will re-order the code to avoid the duplication!

    " I just posted 4 with respect to efficiency"

    But what you posted was totally illegible, wasn't it?!

    "What I want to tell you is that ... you should not set the code optimization level very high in order to prevent such errors."

    That is misleading advice!

    You could justifiably say, as many have before, "if you want source-level debuginng, do not use high optimisation" - but to claim that the higher optimisation levels produce faulty code certainly needs some serious evidence!

Reply
  • "are no big difference between statments inside those cases."

    Which is exactly the kind of thing that an optimiser will spot, and then it will re-order the code to avoid the duplication!

    " I just posted 4 with respect to efficiency"

    But what you posted was totally illegible, wasn't it?!

    "What I want to tell you is that ... you should not set the code optimization level very high in order to prevent such errors."

    That is misleading advice!

    You could justifiably say, as many have before, "if you want source-level debuginng, do not use high optimisation" - but to claim that the higher optimisation levels produce faulty code certainly needs some serious evidence!

Children
No data