From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9EFBF3844054; Thu, 24 Jun 2021 07:36:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9EFBF3844054 From: "joel.bertrand at systella dot fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/101188] New: [AVR] Miscompilation and function pointers Date: Thu, 24 Jun 2021 07:36:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 11.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joel.bertrand at systella dot fr X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2021 07:36:26 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101188 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 LoRa= WAN 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 !=3D 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 c= ode 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 offsettin= g is done. I think this is a codegen bug - the compiler should have either picke= d a different set of regs to subtract R13:R12 from, or should have restored Z w= ith a movw r30, r12 before 0xa34a. Regards, JN=