The following is the email thread with tools support:
*************************************************************************************************************
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
Regards,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.
Kenny
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 processor.tools.support@analog.com, referencing "TAR-47219", for information on how to download and install the patch.