[avr-gcc-list] tool chain bug

[Theodore A. Roth]

I noted this on the list before and there was no response so I've
investigated a bit more. (I synced up with cvs yesterday)

Here's a simple program which demostrates the bug:

cat <<EOF > messy.c
#include <string.h>
#include <inttypes.h>

uint8_t foo[6] = {0, 1, 2, 3, 4, 5};

void main (void)
{
    uint8_t bar[6];
    memcpy (bar,foo,6);

}
EOF

Compiling as such:

avr-gcc -g -O2 -Wall -mmcu=atmega128   -c -o messy.o messy.c
avr-gcc -g -O2 -Wall -mmcu=atmega128 -Wl,-Map,messy.map -o messy messy.o
messy.o(.text+0x18): In function `main':
/home/roth/dev/messy/messy.c:13: relocation truncated to fit: R_AVR_7_PCREL no 
symbol

And disassembling messy.o with `avr-objdump -S messy.o` yields this:

    memcpy (bar,foo,6);
   8:   86 e0           ldi     r24, 0x06       ; 6
   a:   de 01           movw    r26, r28
   c:   11 96           adiw    r26, 0x01       ; 1
   e:   e0 e0           ldi     r30, 0x00       ; 0
  10:   f0 e0           ldi     r31, 0x00       ; 0
  12:   01 90           ld      r0, Z+
  14:   0d 92           st      X+, r0
  16:   8a 95           dec     r24
  18:   01 f4           brne    .+0             ; 0x1a

If I go back to the cvs versions of binutils/gcc from 20020903, which work
for me, I get this code:

    memcpy (bar,foo,6);
   8:   86 e0           ldi     r24, 0x06       ; 6
   a:   de 01           movw    r26, r28
   c:   11 96           adiw    r26, 0x01       ; 1
   e:   e0 e0           ldi     r30, 0x00       ; 0
  10:   f0 e0           ldi     r31, 0x00       ; 0
  12:   01 90           ld      r0, Z+
  14:   0d 92           st      X+, r0
  16:   8a 95           dec     r24
  18:   e1 f7           brne    .-8             ; 0x12

Notice that the "brne" insn at addr 0x18 is messed up.

I have some other code that exhibits the same problem but with "breq" and
"brcc" insns.

I'm not really sure as to which program has the bug, gcc or gas, but
whoever it is, is generating bogus code.

I'll keep digging and see if I can come up with a fix, but I'm really
groping in the dark on this one right now.


Ted Roth

avr-gcc-list at http://avr1.org