[Bug c/101188] New: [AVR] Miscompilation and function pointers

["joel.bertrand at systella dot fr" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188

            Bug ID: 101188
           Summary: [AVR] Miscompilation and function pointers
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: joel.bertrand at systella dot fr
  Target Milestone: ---

Hello,

I'm writing a firmware that runs on an ATmega1284. To build this bare metal
firmware, I have used avr-gcc 5.4.0 and I have seen a strange pointer
corruption. Thus, I have built from scratch a new gcc (11.1.0) that triggers
the same bug.

In a first time, my code is downloadable at
https://hilbert.systella.fr/public/firmware.tar.gz

I have tried to make a simple testcase, but when I remove some unused code,
sometimes, firmware runs as expected. That being said, a lot of code is not
executed. In main.c, I only initialize my board and I only try to send LoRaWAN
packets.

In lorawan/ldl_mac.c, you will find the following code :

#if defined(LDL_FIX_GCC_BUG)
            void app_handler(void *app, enum ldl_mac_response_type type,
                    const union ldl_mac_response_arg *arg);
            if (self->handler != app_handler) for(;;);
#endif

            self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg);

If I undefined LDL_FIX_GCC_BUG, firmware crashes as self->handler seems to be
nullified. With LDL_FIX_GCC_BUG, firmware never stalls in for(;;) and runs as
expected. Of course, self->handler should be equal to app_handler.

If I replace self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg) by
app_handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg), even if I delete code
between #if and #endif, firmware runs also as expected.

Thus, I have checked assembly output.

good_2.S : (https://hilbert.systella.fr/public/good_2.S)

    a318: f6 01       movw r30, r12
...
    a33c: e3 50       subi r30, 0x03 ; 3
    a33e: ff 4f       sbci r31, 0xFF ; 255
    a340: 01 90       ld r0, Z+
    a342: f0 81       ld r31, Z
    a344: e0 2d       mov r30, r0

This loads Z with R13:R12, and then later offsets it by -0xFF03 to
obtain the address of self->handler, which is then used by the icall
instruction.

bad.S : (https://hilbert.systella.fr/public/bad.S)


    a31c: f6 01       movw r30, r12
...
    a340: 68 01       movw r12, r16
    a342: ff e4       ldi r31, 0x4F ; 79
    a344: cf 1a       sub r12, r31
    a346: fe ef       ldi r31, 0xFE ; 254
    a348: df 0a       sbc r13, r31
    a34a: e3 50       subi r30, 0x03 ; 3
    a34c: ff 4f       sbci r31, 0xFF ; 255
    a34e: 01 90       ld r0, Z+
    a350: f0 81       ld r31, Z
    a352: e0 2d       mov r30, r0

Note the clobbering of R31:R30 with immediate values *before* the offsetting is
done. I think this is a codegen bug - the compiler should have either picked a
different set of regs to subtract R13:R12 from, or should have restored Z with
a movw r30, r12 before 0xa34a.

Regards,

JN