[avr-libc-dev] Re: eeprom_read_byte and clr ret_hi

[David Brown]

Weddington, Eric wrote:
> > -----Original Message----- From: 
> > address@hidden 
> > [mailto:address@hidden org]
> > On Behalf Of David Brown Sent: Monday, November 23, 2009 3:25 AM 
> > To: address@hidden Subject: [avr-libc-dev] Re:
> > eeprom_read_byte and clr ret_hi
> >
> > Weddington, Eric wrote:
> > > > -----Original Message----- From: 
> > > > address@hidden 
> > > > [mailto:address@hidden
> > > > org] On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009
> > > > 12:21 AM To: address@hidden Subject: Re:
> > > > [avr-libc-dev] eeprom_read_byte and clr ret_hi
> > > >
> > > > > > eeprom_read_byte returns a uint8_t. Why does it clear r25?
> > > > > >  eerd_byte.S: clr     ret_hi
> > > > > >
> > > > > > Does the AVR ABI require that r25 be zeroed in a function
> > > > returning a
> > > > > > single byte? If not, this instruction could be removed.
> > > > This is a misty point. Look an example:
> > > >
> > > > unsigned char foo1 (unsigned char *p) { return *p; }
> > > >
> > > > extern unsigned char ext2 (void); int foo2 (void) { return
> > > > ext2() + 1; }
> > > >
> > > > Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1() and
> > > >  foo2().  The new Avr-gcc (4.3.3 and 4.4.2) are not clear R25
> > > > in foo1().
> > > >
> > > > Note, the function return value is present only in expression.
> > > > So it is promoted to integer. So it would be better to clear
> > > > R25 in foo1() only (at one place).
> > > I agree that that is the way it should be.
> > I'm a little confused by this - I hope this is not implying a 
> > return to avr-gcc 4.2 R25 clearing?
>
> No, that wasn't my intention. I was merely commenting that the return
> type of the macro/function should not be made int (16-bit), that it
> should be a byte (uint8_t) as the API name implicates. If it is
> returned as a byte, then yes it is implied and I agree that R25
> should not be cleared.

Ah, good - as I hoped.  I just wanted to be sure.

> > Is this regression is news to you, I can take it up in the main
> > avr-gcc mailing list and/or a missed optimisation bug report.
>
> Please fill out a bug report. That way it won't get lost.

I've added it to the WinAVR bug tracker:
<https://sourceforge.net/tracker/?func=detail&aid=2902772&group_id=68108&atid=520074>

Hope that helps!

p.s. - I'm looking forward to gcc 4.5 with LTO.  For small targets like 
the AVR, that should mean full program optimisation for everything, 
including the libraries.