[Bug target/39386] [avr] different computation results for O1 and O0 executables
--- Comment #7 from anitha dot boyapati at atmel dot com 2010-08-23 13:08 --- Created an attachment (id=21547) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21547action=view) Reduced testcase Reduced testcase to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386
[Bug target/39386] [avr] different computation results for O1 and O0 executables
--- Comment #8 from anitha dot boyapati at atmel dot com 2010-08-23 13:25 --- When -O2 is enabled result is 0xFF (255) which is incorrect. The code generated for the following shift operation: 13: return (left right); +00AB: C004RJMP PC+0x0005 Relative jump +00AC: 0F22LSL R18Logical Shift Left +00AD: 1F33ROL R19Rotate Left Through Carry +00AE: 1F44ROL R20Rotate Left Through Carry +00AF: 1F55ROL R21Rotate Left Through Carry +00B0: 952ADEC R18Decrement +00B1: F7D2BRPL PC-0x05Branch if plus 19: g_6= func_1 (g_6, g_6); +00B2: 93200100STS 0x0100,R18 Store direct to data space 'left' is stored in registers R21:R20:R19:R18 as it is typecasted to uint32_t type while 'right' is stored in R18. Because of shift logic, R18 becomes 0xFF in first iteration which is then stored. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386
[Bug target/42240] [4.3/4.4 Regression, avr] wrong epilogue on naked function
--- Comment #12 from anitha dot boyapati at atmel dot com 2010-07-27 11:35 --- confirmed for 4.5.0. Yet to verify for HEAD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
[Bug target/42240] wrong epilogue on naked function
--- Comment #10 from anitha dot boyapati at atmel dot com 2010-07-26 06:49 --- Bug can be confirmed with 4.4.3 version also (With -O2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
[Bug target/42240] wrong epilogue on naked function
--- Comment #9 from anitha dot boyapati at atmel dot com 2010-07-22 11:26 --- I think the bug is not due to 'naked' function. When the naked attribute is removed for __init_seed(void), the following diff can be observed in the assembly file. --- test_without_naked.s2010-07-22 15:53:13.178956400 +0530 +++ test_with_naked.s 2010-07-22 15:52:52.474373900 +0530 @@ -14,10 +14,11 @@ .L2: rjmp .L2 .size main, .-main + .section.init8,ax,@progbits .global__init_seed .type __init_seed, @function __init_seed: -/* prologue: function */ +/* prologue: naked */ /* frame size = 0 */ ldi r24,lo8(__noinit_start+2) ldi r25,hi8(__noinit_start+2) @@ -41,7 +42,6 @@ sts (seedram)+1,r19 sts seedram,r18 /* epilogue start */ - ret .L11: ldi r18,lo8(0) ldi r19,hi8(0) === It can be seen that in case of naked function, 'ret' is not generated. Hence the execution goes into infinite loop. The code generated for epilogue is wrong in few cases for either for naked/normal functions with -O2 enabled. However incase of normal functions, execution is not affected as 'ret' is executed before entering into block labelled .L11 (of main.s). .L11: ldi r18,lo8(0) ldi r19,hi8(0) rjmp .L6 -- anitha dot boyapati at atmel dot com changed: What|Removed |Added CC||anitha dot boyapati at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
[Bug target/25722] Stackpointer is not restored correct at end of function
--- Comment #3 from anitha dot boyapati at atmel dot com 2010-07-19 12:56 --- When I tried with AVR Studio 4.18, Build 684, the program didn't crash. I think the issue is not with compiler. Disassembly looks proper and call to Evaluate() is returned. This can be verified by using breakpoints in assembly statements. 119: Evaluate(); +023E: 940E0056CALL 0x0056 Call subroutine +0240: CFFFRJMP PC-0x Relative jump However when I tried to put breakpoint for 'while' statement, it did not work out as the corresponding source line couldn't be found in the program memory. This differs from the expected behavior. -- anitha dot boyapati at atmel dot com changed: What|Removed |Added CC||anitha dot boyapati at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25722
[Bug target/25722] Stackpointer is not restored correct at end of function
--- Comment #4 from anitha dot boyapati at atmel dot com 2010-07-19 13:03 --- SSA pass pass_remove_useless_stmts() removes useless statements and any code beyond statements like while(1); will not be generated. This might be why the breakpoint at while(TRUE); in the testcase is not recognised [and hence the simulation looks like hanged/or not returned from evaluate() ] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25722
[Bug target/39223] volatile bug on AVR
--- Comment #9 from anitha dot boyapati at atmel dot com 2010-03-08 06:04 --- (In reply to comment #5) Fails with gcc 4.4.3 and gcc 4.5 with -O1. Correction : The bug passes with 4.4.2 and above versions. Code generated can be seen below. func_45: ... rcall func_15 mov r28,r24 mov r29,r25 ldi r22,lo8(1) ldi r23,hi8(1) ldi r24,hlo8(1) ldi r25,hhi8(1) .L9: sbiw r28,0 breq .L8 lds r18,g_54 lds r19,(g_54)+1 lds r20,(g_54)+2 lds r21,(g_54)+3 .L8: ldi r18,lo8(1) -- anitha dot boyapati at atmel dot com changed: What|Removed |Added CC||anitha dot boyapati at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
[Bug target/39223] volatile bug on AVR
--- Comment #5 from anitha dot boyapati at atmel dot com 2010-02-17 11:09 --- Fails with gcc 4.4.3 and gcc 4.5 with -O1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
[Bug target/39223] volatile bug on AVR
--- Comment #6 from anitha dot boyapati at atmel dot com 2010-02-17 11:19 --- An observation - the same file when compiled with -O1 for i386 target also appears to load g_54 using movl instruction. _func_45: ... L11: testw %bx, %bx je L7 movl_g_54, %eax L7: movl$1, 4(%esp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39223
[Bug target/26118] avr-gcc (GCC) 3.4.5 Bug: copying structure through pointer will destroy the pointer
--- Comment #8 from anitha dot boyapati at atmel dot com 2009-08-20 09:46 --- Created an attachment (id=18403) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18403action=view) 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26118
[Bug target/39386] [avr] different computation results for O1 and O0 executables
--- Comment #6 from anitha dot boyapati at atmel dot com 2009-08-10 13:27 --- Confirmed with gcc 4.4.0. Using switch -O0 with avr-gcc 4.4.0 (-mmcu=atmega128) gave the result 0 while -O1 gave 0xFF -- anitha dot boyapati at atmel dot com changed: What|Removed |Added CC||anitha dot boyapati at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386
