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.

    •  Analog Employees 
    on Sep 23, 2011 1:16 PM


    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.

    •  Analog Employees 
    on Nov 8, 2011 2:27 PM

    A compiler patch for this problem is now available. Please contact processor.tools.support@analog.com, 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.