I have two trivial source files obj1.cc: int x(int y) { return y - 10; } obj2.cc: int foo(int bar) { return bar*10; } 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++ -fno-short-enums -mcpu=arm946e-s obj1.cc obj2.cc -Wl,-Ur -o partial_link_result.o -nostdlib -Os $ arm-none-eabi-readelf -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++ -fno-short-enums -mcpu=arm946e-s obj1.cc obj2.cc -Wl,-Ur -o partial_link_result.o -nostdlib -Os -flto $ arm-none-eabi-readelf -a partial_link_result.o | grep enum Tag_ABI_enum_size: small It sure looks to me like something removed `-fno-short-enums` from `COLLECT_GCC_OPTIONS` during the LTO step. I have reproduced the same behavior on several different gcc 4.8 distributions (Mentor's Sourcery 4.8.1, Ubuntu's 4.8.2, and now the gcc-arm-embedded 4.8.3). (The commands above are from Bobby Moretti) The reason is that: if we add -flto option, link time optimization is invoked. And the lto need to call the function run_gcc(unsigned argc, char *argv[]) in lto-wrapper.c. The options in *argv[] are filtered by the following commands: if(!(cl_options[option->opt_index].flags & (CL_COMMON | CL_TARGET | CL_DRIVER | CL_LTO))) continue; So all the options which do not belong to the CL_COMMON|CL_TARGET|CL_DRIVER|CL_LTO groups will be ignored by LTO. And -fno-short-enums is one of these options. I think it is a bug of LTO. Because the option flag_short_enums can change the enum size in the generated object file. We should allow the users to disable this optimization as they like. I suggest we can add the option flag_short_enums to the CL_COMMON group(or CL_LTO group, I am not sure which group is more reasonable). And I have confirmed that this change works. There are several other options that are similar with flag_short_enums which may change the ABI interface. And these options may cause the similar failure in LTO. So how should we deal with these options? Should we develop a new option group which could not be ignored by LTO?
All ABI changing options should be also enabled for LTO and they also deserve handling in lto-opts.c (always stream, not only if explicitely set) and lto-wrapper.c (diagnose mismatches and force a setting for the link stage). At least enabling them for LTO is minimally required, like you suggest.
(In reply to Richard Biener from comment #1) > All ABI changing options should be also enabled for LTO and they also deserve > handling in lto-opts.c (always stream, not only if explicitely set) and > lto-wrapper.c (diagnose mismatches and force a setting for the link stage). > > At least enabling them for LTO is minimally required, like you suggest. Hi Richard, I was dealing with the fno-short-enum bug that LTO ignore the options of fshort-enum and fshort-wchar(fshort-wchar is similar with fshort-enum). I tried to fix this bug by adding these options to LTO group. And this solution works. Right now, I am trying to add some test cases to report some error message for these cases in the previous gcc versions. And these cases will be passed after I add these options to LTO group. For the option of fshort-enum, I catch the Tag_ABI_enum_size from the final executable. And this test case can work very well now. But for the option of fshort-wchar, if I compile the source files without "-flto" option, I can catch the Tag_ABI_PCS_wchar_t from the final executable. If I add the "-flto" option to the compile command, the Tag_ABI_PCS_wchar_t is totally disappeared in the final executable. So I think this is another bug which means the final executable file (or the ABI) is different if we add "-flto" or not. I generated a minimal example.I have two source files: wchar_0.c: #include <stddef.h> wchar_t wc0[]=L”abc”; const wchar_t wc1[]=L”abc”; wchar_1.c: #include <stddef.h> wchar_t b0[]={ L”abc” }; const wchar_t b1[]={ L”abc” }; Firstly, I compile these files without “-flto”: $ arm-none-eabi-gcc -fshort-wchar wchar_0.c wchar_1.c -Wl,-Ur -o without_flto.o -nostdlib -Os $ arm-none-eabi-readelf -A without_flto.o Attribute Section: aeabi File Attributes Tag_CPU_name: "ARM7TDMI" Tag_CPU_arch: v4T Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_PCS_wchar_t: 2 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: small Tag_ABI_optimization_goals: Aggressive Size Then I compile these files with –flto: $ arm-none-eabi-gcc -fshort-wchar wchar_0.c wchar_1.c -Wl,-Ur -o with_flto.o -nostdlib -Os –flto $ arm-none-eabi-readelf -A with_flto.o Attribute Section: aeabi File Attributes Tag_CPU_name: "ARM7TDMI" Tag_CPU_arch: v4T Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: small Tag_ABI_optimization_goals: Aggressive Size So we can see the Tag_ABI_PCS_wchar_t attribute is totally disappeared. What do you think about this?
It seems that Tag_ABI_PCS_wchar_t is emitted from the C-family frontends only via config/arm/arm-c.c (as opposed to any other Tags). Probably because the option is c-family specific. This code needs to move to generic handling (the option enum is shared across all frontends, so that's not a reason to keep it in a C specific file).
(In reply to Richard Biener from comment #3) > It seems that Tag_ABI_PCS_wchar_t is emitted from the C-family frontends only > via config/arm/arm-c.c (as opposed to any other Tags). Probably because > the option is c-family specific. This code needs to move to generic handling > (the option enum is shared across all frontends, so that's not a reason to > keep it in a C specific file). Thanks very much for your comments. So this seems to be a separate issue that the Tag_ABI_PCS_wchar_t need to be moved to LTO frontend at least,but not only the C frontend. May be I need to creat another patch or bug description for this issue.
Author: zqchen Date: Fri Jun 20 04:52:11 2014 New Revision: 211832 URL: https://gcc.gnu.org/viewcvs?rev=211832&root=gcc&view=rev Log: c-family/ChangeLog 2014-06-20 Hale Wang <hale.wang@arm.com> PR lto/61123 * c.opt (fshort-enums): Add to LTO. * c.opt (fshort-wchar): Likewise. testsuite/ChangeLog 2014-06-20 Hale Wang <hale.wang@arm.com> * gcc.target/arm/lto/: New folder to verify the LTO option. * gcc.target/arm/lto/pr61123-enum-size_0.c: New test case. * gcc.target/arm/lto/pr61123-enum-size_1.c: Likewise. * gcc.target/arm/lto/lto.exp: New exp file used to test LTO option. * lib/lto.exp (object-readelf): New procedure. Added: trunk/gcc/testsuite/gcc.target/arm/lto/ trunk/gcc/testsuite/gcc.target/arm/lto/lto.exp trunk/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_0.c trunk/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_1.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/lto.exp
Thanks for Zhenqiang Chen's help. This bug is fixed. Refer to the link https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01429.html
Fixed.
Author: xguo Date: Tue Jul 29 07:11:02 2014 New Revision: 213147 URL: https://gcc.gnu.org/viewcvs?rev=213147&root=gcc&view=rev Log: gcc/c-family/ 2014-07-29 Terry Guo <terry.guo@arm.com> Backport mainline r211832 2014-06-20 Hale Wang <hale.wang@arm.com> PR lto/61123 * c.opt (fshort-enums): Add to LTO. * c.opt (fshort-wchar): Likewise. gcc/testsuite/ 2014-07-29 Terry Guo <terry.guo@arm.com> Backport mainline r211832 2014-06-20 Hale Wang <hale.wang@arm.com> * gcc.target/arm/lto/: New folder to verify the LTO option. * gcc.target/arm/lto/pr61123-enum-size_0.c: New test case. * gcc.target/arm/lto/pr61123-enum-size_1.c: Likewise. * gcc.target/arm/lto/lto.exp: New exp file used to test LTO option. * lib/lto.exp (object-readelf): New procedure. Added: branches/ARM/embedded-4_8-branch/gcc/c-family/ChangeLog.arm branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/ branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/lto.exp branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_0.c branches/ARM/embedded-4_8-branch/gcc/testsuite/gcc.target/arm/lto/pr61123-enum-size_1.c Modified: branches/ARM/embedded-4_8-branch/gcc/c-family/c.opt branches/ARM/embedded-4_8-branch/gcc/testsuite/ChangeLog.arm branches/ARM/embedded-4_8-branch/gcc/testsuite/lib/lto.exp