Bug 43104 - Incorrect code generation for target mcu ATMega164P
Incorrect code generation for target mcu ATMega164P
Status: RESOLVED WORKSFORME
Product: gcc
Classification: Unclassified
Component: target
4.4.3
: P3 major
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-17 14:48 UTC by smalcom
Modified: 2010-09-20 02:25 UTC (History)
2 users (show)

See Also:
Host:
Target: avr-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description smalcom 2010-02-17 14:48:33 UTC
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
Comment 1 Eric Weddington 2010-03-08 20:56:16 UTC
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.

Comment 2 smalcom 2010-03-08 21:15:26 UTC
(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
Comment 3 Eric Weddington 2010-03-08 21:35:43 UTC
(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
> 

Comment 4 smalcom 2010-03-08 21:49:08 UTC
> 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)
Comment 5 Eric Weddington 2010-03-08 23:26:41 UTC
(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.
Comment 6 smalcom 2010-03-09 01:02:53 UTC
Well, I will make necessary tests
Comment 7 Eric Weddington 2010-09-20 02:25:14 UTC
Closing bug as WORKSFORME.