CW miscompiles volatiles?

[jag]

Hello, I just read an article at embedded.com that linked a paper (http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf). So a question arise: how about Codewarrior? Does it compile the volatile vars well or there are errors? I'm concerned mostly with the HC(S)08 and 56F8000E versions of CW. Bye Jack

[regehr]

Hi folks,

I'm one of the authors of the paper in question.

I teach two embedded systems courses that use CodeWarrior, one based on HCS12 and one based on ColdFire.  Overall I'm happy with both chips and with both versions of CodeWarrior!

But yes, the ColdFire C compiler has serious issues with volatiles.  I'd be happy to post examples if people are interested.  We haven't studied the HCS12 port in detail but it seems better-- a bit of spot checking that I've done has turned up no problems.

Anecdote: I got started with this whole volatile project due to my standard lecture on proper use of volatile variables.  A couple years ago I was giving this lecture, which included some C code fragments and their translation into ColdFire asm.  One of the students raised his hand and asked why a particular translation didn't look right-- I answered that I must have cut and pasted wrong.  But later I looked into this and it was the compiler that was wrong.  This eventually snowballed into a long-term testing project.  So far we've reported 129 bugs to various compiler developers.

John Regehr

[regehr]

Looks like I don't have CW for CF installed right now.  But I remember that for example this code is totally optimized away:

volatile int x;

 x |= 0;

Here the "or" does not need to be performed, but there has to be a load from and store to x.

Please keep in mind that I'm not picking on CW here: no compiler that we have tested so far has been free of volatile bugs.

My hand-written test suite is here:

  http://www.cs.utah.edu/~regehr/volatile_stress.c

To test your compiler of choice, just compile this code with your favorite optimization options and see if you believe its results.  I just did this using CW 4.7 for HCS12 and found very little, if anything, that looked suspicious.

John Regehr

[regehr]

Below are a couple of (I claim) mistranslations performed by CW for CF 7.1 when optimizing maximally for speed.

Here g_1 is loaded but the compiler forgets to store it:

;  142: void or_1 (void);
;  143: void or_1 (void)
;  144: {
;
0x00000000                    _or_1:
;                             or_1:
0x00000000  0x4E560000               link     a6,#0
;
;  145:   g_1 |= 0;
;
0x00000004  0x203900000000           move.l   _g_1,d0
;
;  146: }
;
0x0000000A  0x4E5E                   unlk     a6
0x0000000C  0x4E75                   rts      
0x0000000E  0x51FC                   trapf   

Here the loop optimizer improperly collapses five stores into one (LOOP_BOUND is 5):

;  262: void loop_3 (void);
;  263: void loop_3 (void)
;  264: {
;  265:   TYP i;
;
0x00000000                    _loop_3:
;                             loop_3:
0x00000000  0x4E560000               link     a6,#0
0x00000004  0x598F                   subq.l   #4,a7
;
;  266:   volatile TYP z = 0;
;  267:     for (i=0; i<LOOP_BOUND; i++) {
;
0x00000006  0x42AEFFFC               clr.l    -4(a6)
;
;  268:     z += 3;
;  269:       }
;
0x0000000A  0x700F                   moveq    #15,d0
0x0000000C  0x2D40FFFC               move.l   d0,-4(a6)
;
;  270: }
;
0x00000010  0x4E5E                   unlk     a6
0x00000012  0x4E75                   rts     

[CrasyCat]

Hello

The appropriate process to request an improvement in the generated code is to submit a service request.

Click here to submit a service request.

Make sure to attach a code snippet showing the code you want o get optimized.

CrasyCat

[regehr]

SR has been submitted.  Thanks,

John Regehr

[jbezem]

If I understood correctly, Freescale employees are monitoring this forum. So I'd want to ask them a few questions:

The authors of the mentioned article refer to tests they did also with CW. They cannot publish the details because of licensing issues.

1. Has Freescale been aware of this research?

2. Does Freescale have access to the results for CW?

3. Is Freescale willing to allow the results to be published, and therefore grant the authors the rights for publication? Or publish them directly?

4. What is Freescale's response to the apparently found errors in CW?

5. Will these issues, if any, be resolved, and when?

My current interest is of a general nature, my current target environment is Coldfire MCF5233.

If this forum is not the correct place to ask these questions, I apologize, and I will take my questions to my Freescale representative.

Thanks,

Johan Bezem

[J2MEJediMaster]

Yes, we do monitor these forums. For questions like these, you need to contact your Freescale representative.

---Tom

[Lundin]

It would be interesting to see what result they received with CW. My own impression as a user of CW after using it for six years is that it is a very stable compiler.

Sure, I have encountered some bugs in it, but those were mainly related to combining several optimizing compiler options. I haven't encountered any bugs that weren't related to the optimizer, which sounds promising for the problems mentioned with volatile variables in that study.

Also, the study focuses heavily on GCC, which is somewhat infamous for its compiler bugs.

---

I think it is good to put some pressure on the compiler manufacturers regarding this, but at the same time, I'm quite certain 99% of all problems related to volatile variables come from incompetent so-called programmers.

Just check the code on these forums. A whole lot of all ISRs posted here share global variables with the main loop without making them volatile. People making this very basic mistake shouldn't be programming embedded systems in the first place. And that is the real problem in the embedded SW industry: people learn the syntax of the language and then think they are programmers.

Though you can (should) of course buy a static code analysis tool to find lurking run-time bugs related to volatile variables. Yet, if the programmer doesn't understand the warning messages, the tool is wasted.