Update 9 and 10 compiler bug

Discussion created by rilowite on Sep 22, 2011
Latest reply on Dec 15, 2011 by rilowite

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