Post Go back to editing

Update 9 and 10 compiler bug

The following is the email thread with tools support:


Thanks for letting me know.  Our company is in the medical industry and subject to very tight regulatory restrictions, as I'm sure are many other companies using the Blackfin. A bug like this (as rarely as it might present itself) could conceivably be dangerous - maybe even more so because of it's infrequencey, since most of the code will work and might pass pre-existing software verification and validation, even though some rarely used feature could cause undesired behavior.
How many medical devices, aircraft controller hardware, and other high-risk applications are currently in the field using code that was compiled with Updates 9 or 10?
Might I strongly suggest you issue an advisory to all your registered customers, and perhaps a prominent alert on the ADI website?


Thank you for the concise test case. We've been able to reproduce the problem and can confirm that it is a compiler bug.

The problem has existed since Update 9 and happens because the compiler erroneously decides that it can evaluate the second condition at compile-time. You can work around the problem for now by moving one of the constants to global variables. For example:

int myVal = 0xffff;  /* Global variable */...

            if (l1 == g3 || (l1 == myVal && g3 <= (unsigned long) 512))

We are still investigating the exact cause of the problem in the compiler, but we are confident that you are unlikely to see it elsewhere in your application. Update 9 has been in use by many customers for over 6 months and we have received no reports of this problem, nor have we encountered it in the (extensive) testing that each release goes through.

The problem will be fixed in the next Update for VisualDSP++ 5.0

Processor Tools Support


Visual DSP++ 5.0 Update 10 appears to have a compiler bug. I reduced the

actual code I was building to a very small example that shows the problem.

Refer to the "Test Update 10.c" file on line 47, which reads:

            if (l1 == g3 || (l1 == 0xFFFF && g3 <= (unsigned long) 512))

The compiler output as shown in "Test Update 10.s" reads:

// line 47

            CC = R1 == R0;

            if !CC jump .P35L6 (bp);

The effect is that if the first comparison (l1 == g3) fails, the second

comarison after the || operator is never executed because the compiler

doesn't generate any code to handle it.

Please take a look at the enclosed project that demonstrates the problem,

and let me know your conclusions.  If you'd like more info, you may call me

any time at.......

  • Hi!

    Nice work.

    Have you discovered which statement combination exactly leads to such compiler error?

    If this is a rule, it might be really dangerous. Every code have double comparisons.

  • Hi,

    We are still investigating the problem so, at the moment, we are unable to give much more information about it. We can confirm that the problem will only occur in optimized code.

    Although we will do our best to provide some guidance on code sequences that can cause the problem, there is a high likelihood that we will not be able to do so. Compiler problems (especially where the optimizer is concerned) are often related to the way the compiler generates and analyses information about the program (the "internal representation"). These can often be caused by the coincidence of a complex set of circumstances which may be difficult or impossible to map back to a particular source code sequence We realise this is frustrating.

    Our plan is to produce a fix for this problem and make an updated compiler available. Due to our verification and testing processes that compilers go through, it will probably take us 2-3 weeks to do this.


  • According to ADI's response, it's the constants (0xFFFF and 512) in the second comparison that cause the compiler to get confused. If you move either of the constants to a global variable, the problem doesn't occur.

  • A compiler patch for this problem is now available. Please contact, referencing "TAR-47219",  for information on how to download and install the patch.

  • Sorry it took so long.. The fix appears to work, however I see another issue with v10:
    int Test1()
    int i,j;
        for (i = 0; i < 3; i++)
          j = i;
        return j;  // remark/warning 1975 is generated here???
    Generates a warning 1975 on the return of j, which is clearly incorrect.
  • Hi,

    We are also dealing with this problem through our private support system (PR65588) and below is the reply we sent to you in reponse to this.

    The compiler's ability to spot the use of uninitialized variables was enhanced in Update 9, and it now warns about cases where there's a path through the code that could lead to an uninitialized variable being used. In this case, it has spotted that 'j' is set in a 'for' loop, which could be skipped around. Of course, the compiler has failed to spot that, in this case at least, the loop will always be executed and 'j' is guaranteed to be assigned.



  • Hi Colin,

    Thanks for the update.

    I understand that from a technical point of view, these sorts of snafus are pretty innocuous, and gripes about them from customers might seem a little nit-picky. However, I think AD could also do a better job of understanding that from the point of view of process, issues like these can be a big problem.

    In my industry (FDA regulated medical devices) our QOP requires that any compiler warnings be reviewed and explained, even if we decide to pragmatize individual ones away. Having to slog through zillions of lines of source code and explain a bunch of false-positives that suddenly show up is a big cost.

    Looks like  for now we'll just stick with version 8 since it supports the latest ICEs without any of the problems we see in versions 9 & 10.


  • Hi Rick,

    Point taken about having to review and explain false positives - I can understand why that would cause you serious problems. In this case, however, we're talking about a remark,  not a warning, and it's issued in cases where the compiler spots that a variable *might* not get initialized:

    "new.c", line 9 (col. 5): cc1975: {D} remark: variable "j" may be used before being set

    Note that it's not saying that it *isn't* initialized. In your QOP, do you have any leeway to suppress this remark? This can be done by using the compiler switch "-Wsuppress cc1975", and doing this only suppresses this remark - others are still issued.

    We've looked at ways of avoiding false positives such as this, but it involves some changes to the way the compiler optimizes code (basically, changing the order in which certain optimizations are performed). That, of course, carries its own risks. We'd rather stick with some false positives than make changes to the optimizer, especially given that the remark can be suppressed.


  • Hi Kenny,

    Thanks for the response. Yes, we could suppress the remarks, but since we have some dozens of projects the very act of adding the suppresion is a fair amount of work - although I suppose we could grep it into the dpj files.

    But regardless, it's still work. Something we have to notice, figure out the implications, and then decide what to do.  It's sort of like when "our friends in Seattle" release a new version of some common tool and a hotkey suddenly does something differently. Sure, you can deal with it, but you'd rather not have to!

    If the change adds some really useful or important functionality, then that compensates somewhat I think.