RE: [avr-libc-dev] [bug #22878] eeprom_*_word/dword/blockcausehanginATmega256x

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Weddington, Eric
> Sent: Wednesday, April 09, 2008 1:46 PM
> To: Stu Bell; Dmitry K.; address@hidden
> Subject: RE: [avr-libc-dev] [bug #22878] 
> eeprom_*_word/dword/blockcausehanginATmega256x
> 
>  
> 
> > -----Original Message-----
> > From: Stu Bell [mailto:address@hidden 
> > Sent: Wednesday, April 09, 2008 1:39 PM
> > To: Weddington, Eric; Dmitry K.; address@hidden
> > Subject: RE: [avr-libc-dev] [bug #22878] 
> > eeprom_*_word/dword/block causehanginATmega256x
> > 
> > I'm not sure I should respond to this, as I'm not sure what the asm
> > directive ".rept 30000" does.  If I'm way off base, just email me
> > directly and I'll shut up.
> > 
> > The compiled code does show that, for an avr6, the function 
> > pointer code
> > is wrong (okay, not completely right).
> > 
> 
> Well I was responding to Dmitry's claims which he put in a comment at
> the top of the source code:
> 
> /* avr-gcc 4.4-20080404 + binutils 2.18 produce incorrect code: the
> foo4()
>    function stores 0 value to 'vp' variable.
>    Options: -W -Wall -Os -mmcu=atmega2560
>  */
> 
> The code generated by 4.3.0 + Andy's combine patch shows that 
> the foo4()
> function does NOT store 0 value to 'vp' variable. At least that's my
> interpretation. As to the validity of what it is storing, I don't know
> about that.

On further reflection, let me add to the above.

Dmitry, did you mean that this code:
        ldi r24,lo8(gs(foo4))
        ldi r25,hi8(gs(foo4))
        sts (vp)+1,r25
        sts vp,r24
Stores an effective 0 value to 'vp'? That lo8(gs(foo4)) and hi(gs(foo4))
evaluate to zero? I was interpreting what you wrote as it stored an
immediate value of zero to 'vp'. I do not have a FSF GCC stock 4.3.0
(unpatched) on which to reproduce here. Could you perhaps show the
assembly that it produces?

Eric