Re: [avr-gcc-list] AVR GCC Version 3.3 20030421 - taget mega128

[Denis Chertykov]

"Bruce D. Lightner (La Jolla Shores)" <address@hidden> writes:

> Artur,
> 
> > > -----Original Message-----
> > > From: address@hidden
> > > [mailto:address@hidden Behalf Of Bruce D. Lightner
> > > Sent: Friday, August 08, 2003 12:19 AM
> > > To: Denis Chertykov; address@hidden
> > > Cc: E. Weddington
> > > Subject: Re: [avr-gcc-list] AVR GCC Version 3.3 20030421 - taget mega128
> > ...
> > > This likely explains differing behavior we saw for a large application
> > > moved from and AT90S8515/ATmega8515 (under avr-gcc 2.95) to the
> > > ATmega162L.  Lowering the gcc 3.3 optimization level causes the code to
> > ...
> > But this bug esits on the AT90S8515 as well.
> > For clearness - fact that you move from the AT90S8515/ATmega8515 to the
> > ATmega162L doesn't matter for that case. The key point is that you change
> > compiler version.
> 
> True.  We moved from avr-gcc 2.95 to avr-gcc 3.3 because we had no
> choice if we wanted to target the newer ATmega162.  This has always been
> my complaint with "gcc"...high levels of optimization are sometimes
> dangerous!  Of course, with a microcontroller, you typically need high
> levels of optimization to get your application to fit.  I liked avr-gcc
> 2.95 because it was stable...it just took 95 tries to get "gcc version
> 2" right! :-)
> 
> BTW: The code size of our ~8 Kbyte application was reduced by about 15%
> in switching from avr-gcc 2.95 to avr-gcc 3.3, using "-Os" in both
> cases.  Unfortunately, the 15% smaller code with avr-gcc 3.3 is clearly
> not quite correct!


The bug fixed in MAINLINE not in 3.3.
Mainline is 3.4

Denis.