From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107158 invoked by alias); 10 Mar 2015 00:49:23 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 107144 invoked by uid 48); 10 Mar 2015 00:49:19 -0000 From: "gcc-bugzilla at enginuities dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65371] New: arm loop with volatile variable Date: Tue, 10 Mar 2015 00:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: gcc-bugzilla at enginuities dot com X-Bugzilla-Status: UNCONFIRMED 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 cf_gcctarget Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg01031.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65371 Bug ID: 65371 Summary: arm loop with volatile variable Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at enginuities dot com Target: arm-none-eabi (Cortex-M3) I've found this behaviour with gcc 4.8.4, 4.9.2, and 5.0.0 (20150308) (all compiled with the same flags) on Arch Linux (3.18.2-2-ARCH x86_64). I've also had the same behaviour using the precompiled gcc-arm-embedded toolchain from Launchpad (gcc-arm-none-eabi-4_9-2014q4). Compiling func.c: #define PERIPH_BASE 0x4001000 #define PERIPH ((PERIPH_TypeDef *) PERIPH_BASE) typedef struct { volatile unsigned long REG1; } PERIPH_TypeDef; void func() { PERIPH->REG1 |= 0x00010000; while (!(PERIPH->REG1 & 0x00020000)) { } PERIPH->REG1 |= 0x01000000; } With: arm-none-eabi-gcc -mthumb -mcpu=cortex-m3 -Os -c func.c Results in the following disassembly of func.o: 00000000 : 0: 4b06 ldr r3, [pc, #24] ; (1c ) 2: 681a ldr r2, [r3, #0] 4: f442 3280 orr.w r2, r2, #65536 ; 0x10000 8: 601a str r2, [r3, #0] a: 6819 ldr r1, [r3, #0] c: 4a03 ldr r2, [pc, #12] ; (1c ) e: 0389 lsls r1, r1, #14 10: d5fb bpl.n a 12: 6813 ldr r3, [r2, #0] 14: f043 7380 orr.w r3, r3, #16777216 ; 0x1000000 18: 6013 str r3, [r2, #0] 1a: 4770 bx lr 1c: 04001000 streq r1, [r0], #-0 The last line in func.c (PERIPH->REG1 |= 0x01000000;) causes the compiled code to load the address of PERIPH->REG1 in to r2 during the loop at (ldr r2, [pc, #12]) and then use r2 after the loop even though the address contained in r2 was loaded in to r3 at (ldr r3, [pc, #24]) and doesn't change. As such I would expect something like this disassembly of func.o: 00000000 : 0: 4b06 ldr r3, [pc, #24] ; (1c ) 2: 681a ldr r2, [r3, #0] 4: f442 3280 orr.w r2, r2, #65536 ; 0x10000 8: 601a str r2, [r3, #0] a: 681a ldr r2, [r3, #0] c: 0392 lsls r2, r2, #14 e: d5fc bpl.n a 10: 681a ldr r2, [r3, #0] 12: f042 7280 orr.w r2, r2, #16777216 ; 0x1000000 16: 601a str r2, [r3, #0] 18: 4770 bx lr 1a: bf00 nop 1c: 04001000 streq r1, [r0], #-0 arm-none-eabi-gcc -v: Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/home/test_user/toolchain/libexec/gcc/arm-none-eabi/5.0.0/lto-wrapper Target: arm-none-eabi Configured with: /home/test_user/temp/gcc-5-20150308/gcc-5-20150308/configure --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --enable-languages=c,c++ --prefix=/home/test_user/toolchain --target=arm-none-eabi --with-gmp=/home/test_user/toolchain --with-gnu-as --with-gnu-ld --with-mpc=/home/test_user/toolchain --with-mpfr=/home/test_user/toolchain --with-newlib --without-headers Thread model: single gcc version 5.0.0 20150308 (experimental) (GCC)