[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

[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 #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, 0x
> 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 #4 from smal dot root at gmail dot com  2010-03-08 21:49 ---
> I still cannot reproduce the error
you got
>>lds r24, 0x
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.
0x - 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 #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, 0x
> 
> Its mean load data from SRAM at address 0x. 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 #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, 0x

Its mean load data from SRAM at address 0x. 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 #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:

 :
   0:   df 93   pushr29
   2:   cf 93   pushr28
   4:   0f 92   pushr0
   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, 0x
  10:   89 83   std Y+1, r24; 0x01
  12:   80 91 00 00 lds r24, 0x
  16:   89 83   std Y+1, r24; 0x01
  18:   80 91 00 00 lds r24, 0x
  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