[Bug lto/45729] New: -flto conflicts with -mthumb

["rafael dot carre at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

% cat thumb.i 
int _start(void)
{
    extern int f(void);
    return f();
}

% cat arm.i 
int f(void)
{
    int ret;
    asm ("\tmov %0, #0x200\n" : "=r"(ret));
    return ret;
}

% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
thumb.i -c -mthumb                   
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.i -c          
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.o thumb.o -lgcc -nostdlib        
/tmp/cc6zNKqK.s: Assembler messages:
/tmp/cc6zNKqK.s:20: Error: invalid immediate: 512 is out of range
lto-wrapper: /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc returned 1 exit
status
collect2: lto-wrapper returned 1 exit status
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.o thumb.o -lgcc -nostdlib -mthumb   
/tmp/ccIIQlpY.s: Assembler messages:
/tmp/ccIIQlpY.s:20: Error: invalid immediate: 512 is out of range
lto-wrapper: /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc returned 1 exit
status
collect2: lto-wrapper returned 1 exit status
% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -O -flto -mthumb-interwork
arm.o thumb.o -lgcc -nostdlib -mno-thumb


% /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc -v                           
Using built-in specs.
COLLECT_GCC=/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm-elf-eabi-cvs/libexec/gcc/arm-elf-eabi/4.6.0/lto-wrapper
Target: arm-elf-eabi
Configured with: ../gcc-4.6-20100918/configure
--prefix=/usr/local/arm-elf-eabi-cvs --target=arm-elf-eabi --enable-lto
--enable-languages=c --disable-docs --disable-libssp
Thread model: single
gcc version 4.6.0 20100918 (experimental) (GCC) 


I am not sure what is wrong here:

If -mthumb is not specified during linking, I would expect -flto to generate
ARM code which is interworked properly with existing thumb code
If -mthumb is explicited, I would expect -flto to generate Thumb code which is
interworked properly with existing ARM code


Linking with -mno-thumb on a larger binary (rockbox) shows that the binary is
using both Thumb and ARM,
does it mean that -flto doesn't regenerate assembler for every file from the
GIMPLE representation?


-- 
           Summary: -flto conflicts with -mthumb
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rafael dot carre at gmail dot com
GCC target triplet: arm-elf-eabi


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45729