public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "eleventen at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug inline-asm/56884] New: ARM thumb16 mnemonic lsls not recognized for CPU cortex-m0. Date: Mon, 08 Apr 2013 21:48:00 -0000 [thread overview] Message-ID: <bug-56884-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56884 Bug #: 56884 Summary: ARM thumb16 mnemonic lsls not recognized for CPU cortex-m0. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: inline-asm AssignedTo: unassigned@gcc.gnu.org ReportedBy: eleventen@gmail.com It looks like the inline assembler when -mcpu=cortex=m0 is selected doesn't recognize the "lsls" mnemonic. It assembles "lsl" and emits the instruction that the disassembler identifies as "lsls". The hitch is that this mismatch requires different inline assembler when the cpu changes between M0 and M3/M4. On M3, the "lsl" instruction will not set the condition flags. --- Given a source file: void test () { __asm volatile ("lsls r0, #1"); } For Cortex-M0, elf@cerise lsl-bug > /opt/gcc/bin/arm-none-eabi-gcc -g -Os -c -mcpu=cortex-m0 -mthumb lsl.c -o lsl.o /tmp/ccuEyZSU.s: Assembler messages: /tmp/ccuEyZSU.s:29: Error: instruction not supported in Thumb16 mode -- `lsls r0,#1' If the instruction is changed to "lsl r0, #1" the compiler is happy and the emitted machine code is correct. The disassembler accurately identifies the instruction as lsls because that's the only form of lsl that the M0 supports. void test () { __asm volatile ("lsl r0, #1"); 0: 0040 lsls r0, r0, #1 } 2: 4770 bx lr So, I think that the issue is only in the inline assembler in that it doesn't accept the "lsls" opcode....or is there another explanation? --- For references: elf@cerise lsl-bug > /opt/gcc/bin/arm-none-eabi-gcc -v -mcpu=cortex-m0 -mthumb Using built-in specs. COLLECT_GCC=/opt/gcc/bin/arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/opt/gcc/libexec/gcc/arm-none-eabi/4.7.2/lto-wrapper Target: arm-none-eabi Configured with: ../gcc-4.7.2/configure --target=arm-none-eabi --prefix=/opt/gcc --enable-multilib --enable-languages=c,c++ --with-newlib --with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-threads --with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp --disable-werror --with-system-zlib --disable-newlib-supplied-syscalls Thread model: single gcc version 4.7.2 (GCC)
next reply other threads:[~2013-04-08 21:48 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-04-08 21:48 eleventen at gmail dot com [this message] 2013-04-08 21:49 ` [Bug inline-asm/56884] " pinskia at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-56884-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).