Compiler error? Unlikely, but ...

Once I liked the saying “Do you think that a compiler error? Check your code better! ” Indeed, in my practice this happened - when, it would seem, all the rational reasons for the error were rejected and the thought that this time there was certainly a glitch somewhere in the system, suddenly there was some ridiculously banal error in its code , immediately explaining all the previous oddities.

But sometimes the compiler may still be guilty.


The project on the TMS570 controller (one of the key features of which influenced the choice was the presence of a floating-point module). The purpose of a controller for a safety-critical system does not seem to leave a chance that any serious problems may occur with the controller itself. At least, I really want to believe this.
')
The project has a very, very complex algorithm that requires a lot of floating-point calculations. Which, of course, refuses to work on the first implementation attempt. No wonder, normal development and debugging.

But then the strangeness begins. Where the values ​​of the calculations can never be greater than 1, the error of the “infinite result” suddenly begins to occur. In this attempt to catch the moment, when this happens, do not lead to success.

The final was the following: fragment

if (x > 1) { printf(“%f”, x); } 

printed out values ​​of the form 0.0043, i.e. much less than one ...

And here the idea that “perhaps, this time the compiler is to blame,” has once again become more active. And after some digging in this direction, the problem was suspected, confirmed, and successfully solved.

The point was that the compiler incorrectly generated the interrupt input / output code without saving all the floating point registers! As a result, as soon as during the execution of any floating-point calculations an interrupt occurred, within which floating-point calculations were also performed (and this really happened!), The system began to behave in an unpredictable way like the one described above. And after manually correcting the interrupt I / O code, the problem was safely solved and no longer manifested itself.

Shl. And when you know where exactly the problem is, it is already easy to find that it was known before. Unfortunately, information about it was present only on the Texas Instruments forum , and was not described anywhere in standard documentation or among known problems.

ZZY. Well, even the purpose of the controller for safety critical systems, as it turned out, does not guarantee that everything in it will work as stated ...