Update 9 and 10 compiler bug

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.

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.

Regards,

Colin.

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.

-Rick

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.

Kenny

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.

-Rick