[avr-gcc-list] Re: WinAVR 20050214 (gcc 3.4.3) and optimizer bug.

[Joerg Wunsch]

As Vesa Jääskeläinen wrote:

> I have been debugging why Ethernut brakes in certain situations with
> gcc. And found an optimizer bug.

I can't seem to find one.

> We can see that one compare is missing and this causes functional
> change to code.

Which one is missing do you think?  The full assembler code shows all
of them:

.global test
        .type   test, @function
test:
/* prologue: frame size=0 */
/* prologue end (size=0) */
        movw r30,r22
        ld r18,Z
        ldd r19,Z+1
        ldd r20,Z+2
        ldd r21,Z+3
        cpi r24,1
        cpc r25,__zero_reg__
        breq .L3
        sbiw r24,2
        breq .L5
        ret
.L3:
        tst r18
        breq .L1
/* #APP */
        nop ; bv needs to be defined and used
/* #NOAPP */
        ret
.L5:
/* #APP */
        nop ; entry to case 2
/* #NOAPP */
        ld r24,Z
        ldd r25,Z+1
        or r24,r25
        breq .L6
/* #APP */
        nop ; ppv and *ppv are not zeros
/* #NOAPP */
        ret
.L6:
/* #APP */
        nop ; either ppv or *ppv is zero
/* #NOAPP */
.L1:
        ret
/* epilogue: frame size=0 */
/* epilogue: noreturn */
/* epilogue end (size=0) */
/* function test size 29 (29) */
        .size   test, .-test
/* File "doo.c": code   29 = 0x001d (  29), prologues   0, epilogues   0 */

Don't rely on annotated disassembled code.  In your case, it seems the
optimizer moved parts of the conditionals into the function
initialization, so it was not assigned to some line number in the
debugging information.  For that reason, the annotator didn't tell you
about it.

At least from an eyeball review, the above assembler code (produced by
GCC 3.4.3 for an ATmega128 target, in case it matters) looks identical
to your C code to me.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)