there is a bug in avr-gcc (GCC) 3.4.5, that comes with the latest WinAVR distribution (20060125). The avr-gcc (GCC) 3.4.3, that comes with WinAVR 20050214 does NOT contain this bug. The bug exists with and without optimization (I tried -O0 and -Os) If you try to copy a structure with *struct_pointer = struct; the struct_pointer gets destroyed. The assembler code generated seems to add one structure length foreach copied byte to the pointer. The complete code is attached. (there I use *struct_pointer++, but it is the same problem there).
Created attachment 10783 [details] Complete project.
Created attachment 10791 [details] preprocessed source demonstrating bug produced with commandline: avr-gcc -E -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 main.c -o main.i
Created attachment 10792 [details] assembly output from previous preprocessed source Generated with commandline: avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o Using gcc 3.4.5 on Win32 host, avr target.
Comment on attachment 10792 [details] assembly output from previous preprocessed source assembly output from previous preprocessed source Generated with commandline: avr-gcc -c -mmcu=atmega32 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -std=gnu99 -MD -MP -MF .dep/main.o.d main.c -o main.o Using gcc 3.4.5 on Win32 host, avr target. In the first two examples ( *ptr++ = struct; and memcpy(ptr++, &struct, sizeof(struct)); ) the source pointer is being incremented by sizeof(struct) for each byte being copied. In the third example, the pointer increment is set aside as a distinct statement. Here, things behave as expected.
You are right, *ptr = struct; ptr++; works.I must have mixed up some of my testing results. Cajus
After tracking it down, it turns out to be the following change, introduced between GCC 3.4.3 and 3.4.4: 2005-03-19 Andy Hutchinson <HutchinsonAndy@netscape.net> PR target/18251 * config/avr/avr.md (movstrhi): Rewrite as RTL loop. (*movstrqi_insn): Delete. (*movstrhi): Delete. Here's the corresponding SVN log entry: Revision 96732 - (view) (download) - [select for diffs] Modified Sat Mar 19 15:45:41 2005 UTC (11 months, 1 week ago) by marekm File length: 79688 byte(s) Diff to previous 96394 (colored) PR target/18251 * config/avr/avr.md (movstrhi): Rewrite as RTL loop. (*movstrqi_insn): Delete. (*movstrhi): Delete. When unpatching the diff for that revision, the generated code for the testcase looks OK again.
Is this still an issue with current trunk? gcc 3.4 has been out of maintenance for some time.
Created attachment 18403 [details] Images display the contents of rx_tel_in_ptr before and after the assignment This issue does not arise with avr-studio 4.17 (win-avr 4.3.2). The memory contents of rx_tel_in_ptr before assignment and after increment are observed. The contents of RXtemp got copied to the address pointed by rx_tel_in_ptr as well as the pointer is post-incremented. Screenshots attached.
According to comment #8, the problem no longer exists in gcc 4.3.2. Closing bug as WONTFIX.