Re: [avr-gcc-list] What GCC bug currently effect the AVR port of GCC?

[Brian Dean]

On Tue, Mar 01, 2005 at 12:57:10PM +0100, Joerg Wunsch wrote:

> > But are you now thinking that this was once fixed but has now been
> > reverted, either accidentally or on purpose?
> 
> It's probably best to read the CVS logs/diffs of GCC for this.

I checked the CVS logs for gcc and I can't find where your patch was
committed, so maybe it never was.  That's a real shame, especially
since your patch seems to work so well (with the exception of post and
pre increment as you mentioned).  The last message from Marek in the
thread you referred to on your web site indicated support for it at
least under the condition that it only affected writes to volatile
locations - which your patch does.  All register accesses would be
volatile by definition so that works.  And if SRAM data happened to be
declared volatile, the potential optimization loss would be washed out
by the volatile attribute anyway.  Thus it sounds like your patch does
the right thing where it matters, and it doesn't compromize possible
optimizations where it doesn't matter.  Win-win.

Note that this is needed for more than just timer registers as someone
else mentioned.  The output compare registers require it also, and one
commonly sets output compare registers when controlling h-bridges for
motor control and zillions of other applications in the AVR space.
Most robots have more that one motor, and it's tempting to write code
that uses a struct to encompass motor parameters:

     struct motor_t {
       volatile uint16_t * pwmreg;
       ...
     } MOTOR;

     MOTOR left  = { &OCR3A, ... };
     MOTOR right = { &OCR3B, ... };

     ...

      *left.pwmreg  = FORWARD;
      *right.pwmreg = REVERSE;

Except that without your patch, the above two lines generate incorrect
code.  The alternative is to write in-line functions that get the
order correct, but that is ugly and non-intuitive compared to the
above:

      write_high_byte_first(left.pwmreg, FORWARD);
      write_high_byte_first(right.pwmreg, REVERSE);

Not to mention all the needless head-scratching that leads one to
check the generated assembler in the first place where they can
discover the bug, only after determining they are getting "funny"
values in the output compare registers, and that only after checking
every other possible code-path of their program to try to find the
culprit in their code because, since 99.999% of the time, the problem
is due to a programmer error as opposed to a compiler error.

Yuck.  I hope this can just be fixed and that will be one less errata
and known problem that needs to be documented and repeated debugged.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/