• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 1001 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 CCS compiler troubles of “if statement”.

trout
Expert 6930 points
Other Parts Discussed in Thread: MSP430F5419A

Champs,

Our customer has complained that his subroutine in if statement, sub_a(), is called twice. The device is MSP430F5419A.

   if(sub_a(1))    {

           c = true;

   }

I’ve made the attached test code and confirmed his trouble. In the test code, called counters, cntA and cntB, show 2.

bool sub_a(int a)

{

        cntA++;

        return a>0 ? true : false;

}

F5438a_sub_CCSv6.zip

 

But with inserting two NOP, the trouble isn’t caused, cntA shows 1.

   if(sub_a(1))

   {

           __no_operation();

           c = true;

           __no_operation();

   }

I’ve confirmed with CCSv5 and CCSv6, default optimization. The device is F5438A.

CCS Version: 5.5.0.00077, TIv4.2.7(eabi)

CCS Version: 6.1.0.00104, TIv4.4.4(eabi)

 

Let us know how to avoid this trouble, please.

 

Regards,
Kazuo Yamauchi

  • 0
    TI__Guru**** 238965 points

    Thank you for informing us about this situation.  It appears to be a compiler bug.  I filed SDSCM00051809 in the SDOWP system to have this investigated.  Feel free to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0
    TI__Expert 4930 points
    Yes, it's a compiler bug.

    The compiler is trying to turn the IF into "c = sub_a(1)" via the intermediate expression "c = (sub_a(1) & 1) | ((sub_a(1) ^ 1) & 0)", when it realises that sub_a() has a side effect -- it modifies cntA -- and converts it into the two calls you see. The bug is that it didn't check for the side effect sooner; it is not correct to duplicate calls like that when there is a side effect. It will be fixed in the next release.

    The problem will arise when you have "if (P) X=A; else X=B;" where A and B are either 0 or 1 and P is known to return only 0 and 1.

    One way to avoid it is to write "c = sub_a(1)" instead of the IF that sets c to true or false. Another way is what you found, to insert one or more __no_operation() statements in one or both arms of the IF. A simple conversion from IF to ?: form will not help.

    (By the way, you could also write sub_a() as "return a>0" instead of explicitly returning true or false. It doesn't help this problem, but it's easier to read.)