bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug gas/15348] New: GCC inline assembler for ARM thumb16 mnemonic lsls


From: eleventen at gmail dot com
Subject: [Bug gas/15348] New: GCC inline assembler for ARM thumb16 mnemonic lsls not recognized for CPU cortex-m0
Date: Mon, 08 Apr 2013 22:02:07 +0000

http://sourceware.org/bugzilla/show_bug.cgi?id=15348

             Bug #: 15348
           Summary: GCC inline assembler for ARM thumb16 mnemonic lsls not
                    recognized for CPU cortex-m0
           Product: binutils
           Version: 2.23
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gas
        AssignedTo: address@hidden
        ReportedBy: address@hidden
    Classification: Unclassified


Feedback from GCC maintainers is that this issue is the responsibility of
binutils.

 ---

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,

address@hidden 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:

address@hidden 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)

address@hidden lsl-bug > /opt/gcc/bin/arm-none-eabi-as --version
GNU assembler (GNU Binutils) 2.23.1
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.

address@hidden lsl-bug > /opt/gcc/bin/arm-none-eabi-ld --version
GNU ld (GNU Binutils) 2.23.1
Copyright 2012 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]