[Bug c/17336] AVRGCC ignores "volatile" keyword for "register" variables
--- Comment #7 from urjaman at gmail dot com 2008-08-07 07:51 ---
I did a simple test on my avr-gcc 4.2.2 and it seems that this bug (i dont
think it should be Resolution: INVALID but...) is fixed in 4.2.2 atleast. I
changed the register used in the example to r2 to see if the AVR's incapability
to do andi (AND immediate) on r0-r15 would cause any problems, but even this
didnt cause the bug. Here's the objdump output:
while(1)
{
if ( flags & 0x02 ) // Some event detected
8: 21 fe sbrsr2, 1
a: fe cf rjmp.-4 ; 0x8
{
flags &= (0xFF-0x02); // Clear flag
c: 8d ef ldi r24, 0xFD ; 253
e: 28 22 and r2, r24
10: 21 fe sbrsr2, 1
12: fa cf rjmp.-12; 0x8
14: fb cf rjmp.-10; 0xc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17336
[Bug target/27663] missed-optimization transforming a byte array to unsigned long
--- Comment #3 from urjaman at gmail dot com 2009-04-24 20:24 --- Confirmed on 4.3.2 - it's a bit different and actually worse (longer): (Please add 4.3.2 to known to fail - i cant) : 0: e8 2f mov r30, r24 2: f9 2f mov r31, r25 4: 21 81 ldd r18, Z+1; 0x01 6: 30 e0 ldi r19, 0x00 ; 0 8: 40 e0 ldi r20, 0x00 ; 0 a: 50 e0 ldi r21, 0x00 ; 0 c: 52 2f mov r21, r18 e: 44 27 eor r20, r20 10: 33 27 eor r19, r19 12: 22 27 eor r18, r18 14: 82 81 ldd r24, Z+2; 0x02 16: 90 e0 ldi r25, 0x00 ; 0 18: a0 e0 ldi r26, 0x00 ; 0 1a: b0 e0 ldi r27, 0x00 ; 0 1c: a8 2f mov r26, r24 1e: b9 2f mov r27, r25 20: 99 27 eor r25, r25 22: 88 27 eor r24, r24 24: 28 2b or r18, r24 26: 39 2b or r19, r25 28: 4a 2b or r20, r26 2a: 5b 2b or r21, r27 2c: 84 81 ldd r24, Z+4; 0x04 2e: 90 e0 ldi r25, 0x00 ; 0 30: a0 e0 ldi r26, 0x00 ; 0 32: b0 e0 ldi r27, 0x00 ; 0 34: 28 2b or r18, r24 36: 39 2b or r19, r25 38: 4a 2b or r20, r26 3a: 5b 2b or r21, r27 3c: 83 81 ldd r24, Z+3; 0x03 3e: 90 e0 ldi r25, 0x00 ; 0 40: a0 e0 ldi r26, 0x00 ; 0 42: b0 e0 ldi r27, 0x00 ; 0 44: ba 2f mov r27, r26 46: a9 2f mov r26, r25 48: 98 2f mov r25, r24 4a: 88 27 eor r24, r24 4c: 28 2b or r18, r24 4e: 39 2b or r19, r25 50: 4a 2b or r20, r26 52: 5b 2b or r21, r27 54: 62 2f mov r22, r18 56: 73 2f mov r23, r19 58: 84 2f mov r24, r20 5a: 95 2f mov r25, r21 5c: 08 95 ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27663
[Bug target/57339] [SH] Wrong ISR FPU register save/restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57339 Urja Rannikko changed: What|Removed |Added CC||urjaman at gmail dot com --- Comment #2 from Urja Rannikko --- (In reply to Oleg Endo from comment #0) > On SH2A and SH2E R0 is not a banked register and must be pushed before > dealing with the FP regs. This is false for atleast SH2A, that is, r0 is a banked register on SH2A. I dont know about SH2E. A small quote from the sh2a software manual (2.2.6 Register Banks) (Rev 3.00): "For the nineteen 32-bit registers comprising general registers R0 to R14, control register GBR, and system registers MACH, MACL, and PR, high-speed register saving and restoration can be carried out using a register bank. "
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
Urja Rannikko changed:
What|Removed |Added
CC||urjaman at gmail dot com
--- Comment #20 from Urja Rannikko ---
I'll add a note here that this seems to also affect the AVR target when it is
under register pressure and cant use Z or Y registers which can do Z+n /Y+n
addressing, it ends up doing really stupid things with X register (aka r26:r27)
(which could post-inc):
adiwr26, 0x01
ld r24, X
sbiwr26, 0x01
(followed by adiw r26, 2...)
This was my test case for showing this behaviour on AVR:
unsigned char test_0 (unsigned char* p1, unsigned char *p2, unsigned char *p3)
{
unsigned char r = 0;
r += *p1++;
r += *p2++;
r += *p3++;
r += *p1++;
r += *p2++;
r += *p3++;
r += *p1++;
r += *p2++;
r += *p3++;
return r;
}
This note added for anyone later trying to google for this after seeing that X
reg stupidity on AVR, sorry for maybe-a-bit-noise ...
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #22 from Urja Rannikko ---
All of the 3 pointer regs (X,Y,Z) can do post-inc operations, but only Y and Z
can do displacement (which is what gcc tries to use, even when the increment
operation would be better all around since we usually want the +4 pointer).
The given code wasnt meant to be anywhere near the real code, just a code that
shows the behaviour exists. The real code is just a function with lots going on
involving loading 32-bit values from pointers.
This code is WIP and i was just looking how it'll end up compiled, but for your
curiosity, here's a fragment (not enough to compile), with a comment added on
the part where i found the ld, adiw, ld, sbiw, adiw, ld, sbiw, adiw, ..
sequence, but AFAIK it could be triggered at any usage of inlined buf2u32:
static uint32_t buf2u32(uint8_t *buf) {
return *(uint32_t*)buf;
}
static uint8_t do_exec_opbuf_extwrite(uint8_t *ewsq, uint32_t addr, uint8_t
*buf, uint16_t dlen) {
uint8_t* end = ewsq + ewsq[0] + 1;
for (uint16_t i=0;iend) return 1;
}
return 0;
}
If i end up liking this code enough it'll end up in a branch at
https://github.com/urjaman/libfrser
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 Urja Rannikko changed: What|Removed |Added CC||urjaman at gmail dot com --- Comment #18 from Urja Rannikko --- This fix seems to have caused an another problem on AVR, as described on arch linux bug tracker https://bugs.archlinux.org/task/49284#comment149872 Also my software (this example being https://github.com/urjaman/frser-m328lpcspi ) fails to build with similar output: avr-gcc -mmcu=atmega328p -O3 -Wl,--relax -fno-tree-switch-conversion -Wall -W -pipe -flto -flto-partition=none -fwhole-program -std=gnu99 -Ilibfrser -std=gnu99 -I./ -o frser-m328lpcspi.out main.c uart.c flash.c ciface.c console.c lib.c appdb.c commands.c libfrser/frser.c libfrser/udelay.c libfrser/dxprint.c libfrser/spilib.c libfrser/spihw_avrspi.c libfrser/lpcfwh.c nibble.c /tmp/ccMVXcOJ.lto.o: In function `spi_spiop_end': :(.text+0x12e6): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' /tmp/ccMVXcOJ.lto.o: In function `frser_main': :(.text+0x1338): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x1362): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x1370): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x13dc): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x13e4): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x13ec): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x140e): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x1428): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' :(.text+0x1450): relocation truncated to fit: R_AVR_7_PCREL against `no symbol' Not all software fails (simpler/smaller stuff seems to work), but this is pretty bad, should we open a seperate bug or what?
