[Bug c/43104] New: Incorrect code generation for target mcu ATMega164P

[Bug c/43104] New: Incorrect code generation for target mcu ATMega164P

[smal dot root at gmail dot com]

Source

volatile uint8_t mUsart0BufferReadPtr;

void Usart0AtModeSkipLine(void)
{
uint8_t rdptr = 0;

        rdptr = mUsart0BufferReadPtr;
        rdptr = mUsart0BufferReadPtr;
        rdptr = mUsart0BufferReadPtr;
}
-------------
Generated asm
+00000694:   93DF        PUSH      R29            Push register on stack
+00000695:   93CF        PUSH      R28            Push register on stack
+00000696:   920F        PUSH      R0             Push register on stack
+00000697:   B7CD        IN        R28,0x3D       In from I/O location
+00000698:   B7DE        IN        R29,0x3E       In from I/O location
179:      uint8_t rdptr = 0;
+00000699:   8219        STD       Y+1,R1         Store indirect with
displacement
181:            rdptr = mUsart0BufferReadPtr;
+0000069A:   91800000    LDS       R24,0x0000     Load direct from data space
+0000069C:   8389        STD       Y+1,R24        Store indirect with
displacement
182:            rdptr = mUsart0BufferReadPtr;
+0000069D:   91800264    LDS       R24,0x0264     Load direct from data space
+0000069F:   8389        STD       Y+1,R24        Store indirect with
displacement
183:            rdptr = mUsart0BufferReadPtr;
+000006A0:   91800264    LDS       R24,0x0264     Load direct from data space
+000006A2:   8389        STD       Y+1,R24        Store indirect with
displacement

------------------------
OS: WinXP
gcc: avr-gcc.EXE (WinAVR 20100110) 4.3.3


-- 
           Summary: Incorrect code generation for target mcu ATMega164P
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: smal dot root at gmail dot com
  GCC host triplet: Win32
GCC target triplet: avr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[eric dot weddington at atmel dot com]

------- Comment #1 from eric dot weddington at atmel dot com  2010-03-08 20:56 -------
I cannot reproduce the problem.

Used this command line:
avr-gcc -save-temps -O0 -mmcu=atmega164p -c test.c -o test.o

Generated this assembly:

        .file   "test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__  = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
        .text
.global Usart0AtModeSkipLine
        .type   Usart0AtModeSkipLine, @function
Usart0AtModeSkipLine:
        push r29
        push r28
        push __tmp_reg__
        in r28,__SP_L__
        in r29,__SP_H__
/* prologue: function */
/* frame size = 1 */
        std Y+1,__zero_reg__
        lds r24,mUsart0BufferReadPtr
        std Y+1,r24
        lds r24,mUsart0BufferReadPtr
        std Y+1,r24
        lds r24,mUsart0BufferReadPtr
        std Y+1,r24
/* epilogue start */
        pop __tmp_reg__
        pop r28
        pop r29
        ret
        .size   Usart0AtModeSkipLine, .-Usart0AtModeSkipLine
        .comm mUsart0BufferReadPtr,1,1
.global __do_clear_bss

and the object code disassembly was this:


test.o:     file format elf32-avr


Disassembly of section .text:

00000000 <Usart0AtModeSkipLine>:
   0:   df 93           push    r29
   2:   cf 93           push    r28
   4:   0f 92           push    r0
   6:   cd b7           in      r28, 0x3d       ; 61
   8:   de b7           in      r29, 0x3e       ; 62
   a:   19 82           std     Y+1, r1 ; 0x01
   c:   80 91 00 00     lds     r24, 0x0000
  10:   89 83           std     Y+1, r24        ; 0x01
  12:   80 91 00 00     lds     r24, 0x0000
  16:   89 83           std     Y+1, r24        ; 0x01
  18:   80 91 00 00     lds     r24, 0x0000
  1c:   89 83           std     Y+1, r24        ; 0x01
  1e:   0f 90           pop     r0
  20:   cf 91           pop     r28
  22:   df 91           pop     r29
  24:   08 95           ret


So we need a complete test case, along with a command line that can reproduce
the problem.


-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[smal dot root at gmail dot com]

------- Comment #2 from smal dot root at gmail dot com  2010-03-08 21:15 -------
(In reply to comment #1)
> I cannot reproduce the problem.
> 
>    c:   80 91 00 00     lds     r24, 0x0000

Its mean load data from SRAM at address 0x0000. Variable (in our case
mUsart0BufferReadPtr) has address not equal to zero.

In my first post i use three equal strings
rdptr = mUsart0BufferReadPtr;
because first generated with error


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[eric dot weddington at atmel dot com]

------- Comment #3 from eric dot weddington at atmel dot com  2010-03-08 21:35 -------
(In reply to comment #2)
> (In reply to comment #1)
> > I cannot reproduce the problem.
> > 
> >    c:   80 91 00 00     lds     r24, 0x0000
> 
> Its mean load data from SRAM at address 0x0000. Variable (in our case
> mUsart0BufferReadPtr) has address not equal to zero.
> 
> In my first post i use three equal strings
> rdptr = mUsart0BufferReadPtr;

I still cannot reproduce the error with the information that you've given me.
You need to provide a test case that can reproduce the error.
> because first generated with error
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[smal dot root at gmail dot com]

------- Comment #4 from smal dot root at gmail dot com  2010-03-08 21:49 -------
> I still cannot reproduce the error
you got
>>lds     r24, 0x0000
that is error!
address of variable is NULL. Address of
volatile uint8_t SomeVariable
cant be NULL in any case.
----------
Data Memory Map for ATmega164P/324P/644P.
0x0000 - 0x001F - 32 Registers
0x0020 - 0x005F - 64 I/O Registers
0x0060 - 0x00FF - 160 Ext I/O Reg.
0x0100 - 0x04FF/0x08FF/0x10FF - Internal SRAM (1024/2048/4096 x 8)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[eric dot weddington at atmel dot com]

------- Comment #5 from eric dot weddington at atmel dot com  2010-03-08 23:26 -------
(In reply to comment #4)
> > I still cannot reproduce the error
> you got
> >>lds     r24, 0x0000
> that is error!

Take a look at the generated assembly. 3 accesses to the same variable. The
disassembly shows 3 accesses to the same address. Please note that this
disassembly is from the object code, not a final executable (before linking)
because the test case you gave did not include a main() and therefore cannot be
linked.

Again, it is up to you, the bug reporter, to provide a compilable and linkable
test case that can be reproduced to show the error.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[smal dot root at gmail dot com]

------- Comment #6 from smal dot root at gmail dot com  2010-03-09 01:02 -------
Well, I will make necessary tests


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104

[Bug target/43104] Incorrect code generation for target mcu ATMega164P

[eric dot weddington at atmel dot com]

------- Comment #7 from eric dot weddington at atmel dot com  2010-09-20 02:25 -------
Closing bug as WORKSFORME.


-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43104