gcc appears to ignore -fno-short-enums when used with LTO

[Bobby Moretti <bobmoretti at gmail dot com>]

Hi,

I'm using a bare-metal ARM toolchain gcc. I would like to compile my
project with link-time optimization, but I'm running into some
trouble.

I've boiled this down to a fairly simple test case. I asked this
question over at stackoverflow
(http://stackoverflow.com/questions/23174168/gcc-sourcery-codebench-2013-11-link-time-optimization-ignoring-fno-short-enum),
but I think the solution to this will depend on some GCC internals,
and it's unlikely to get a good answer over there.

I would appreciate some pointers from someone who knows more about gcc
internals than myself.

I have two trivial source files

obj1.cc:

    int x(int y)
    {
        return y - 10;
    }

obj2.cc:

    int foo(int bar)
    {
        return bar*10;
    }

I am using Sourcery codebench lite 2013.11:

    $ arm-none-eabi-g++ --version
      arm-none-eabi-g++.exe (Sourcery CodeBench Lite 2013.11-24) 4.8.1

I compile each source file using

    $ arm-none-eabi-g++.exe -fno-short-enums -mcpu=arm946e-s -c
obj1.cc -o obj1.o  -Os -flto
    $ arm-none-eabi-g++.exe -fno-short-enums -mcpu=arm946e-s -c
obj2.cc -o obj2.o  -Os -flto

If I link them without -flto, link time optimization is not invoked,
and I get an object file marked as having int-sized enums:

    $ arm-none-eabi-g++.exe -fno-short-enums -mcpu=arm946e-s obj1.cc
obj2.cc -Wl,-Ur -o partial_link_result.o -nostdlib -Os
    $ arm-none-eabi-readelf.exe -a partial_link_result.o | grep enum
      Tag_ABI_enum_size: int

But if I simply add `-flto` to the linker invocation, the output
claims that it has small enums:

    $ arm-none-eabi-g++.exe -fno-short-enums -mcpu=arm946e-s obj1.cc
obj2.cc -Wl,-Ur -o partial_link_result.o -nostdlib -Os -flto
    $ arm-none-eabi-readelf.exe -a partial_link_result.o | grep enum
      Tag_ABI_enum_size: small

If I run the link step with `-v`,  I can see this when gcc gets to the
lto stage:

    gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-24)
    COLLECT_GCC_OPTIONS='-c' '-fexceptions' '-mcpu=arm946e-s'
'-mcpu=arm946e-s' '-nostdlib' '-Os' '-v' '-D'
'__CS_SOURCERYGXX_MAJ__=2013' '-D' '__CS_SOURCERYGXX_MIN__=11' '-D'
'__CS_SOURCERYGXX_REV__=24' '-dumpdir' './' '-dumpbase'
'partial_link_result.o.wpa'
'-fltrans-output-list=C:\Users\BOBBY_~1\AppData\Local\Temp\ccrOoESe.ltrans.out'
'-fwpa' '-fresolution=C:\Users\BOBBY_~1\AppData\Local\Temp\cccj0syW.res'
'-D' '__CS_SOURCERYGXX_MAJ__=2013' '-D' '__CS_SOURCERYGXX_MIN__=11'
     '-D' '__CS_SOURCERYGXX_REV__=24'
     c:/program files
(x86)/sourcery/lib/gcc/../../libexec/gcc/arm-none-eabi/4.8.1/lto1.exe
-quiet -dumpdir ./ -dumpbase partial_link_result.o.wpa -mcpu=arm946e-s
-mcpu=arm946e-s -auxbase ccQXQ7aT -Os -version -fexceptions
-fltrans-output-list=C:\Users\BOBBY_~1\AppData\Local\Temp\ccrOoESe.ltrans.out
-fwpa -fresolution=C:\Users\BOBBY_~1\AppData\Local\Temp\cccj0syW.res
@C:\Users\BOBBY_~1\AppData\Local\Temp\ccDElvyi

I tried to follow what was going on by exploring gcc lto and
lto-wrapper source code, but it's doing a lot of things and difficult
to follow.

I reproduce the exact same behavior in Ubuntu 14.04 using the
arm-none-eabi-gcc 4.8.2-14ubuntu1+6 toolchain
(http://packages.ubuntu.com/trusty/devel/gcc-arm-none-eabi).

It sure looks to me like something removed `-fno-short-enums` from
`COLLECT_GCC_OPTIONS` during the LTO step. I suspect this might be a
general gcc problem, and not restricted to the Sourcery build.

I need gcc to generate object files without short enums in order to
link against certain libraries built with 32 bit enums. Is there any
way to accomplish this?

Thanks,

Bobby Moretti
bobmoretti@gmail.com