https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80838
--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
OK, found the problem. LTO binary is built with -fPIC because of the way we
merge options. I saw the same problem previously on Firefox. It is easy
mistake to do. I think we should
1) warn in this case
2) downgrade options, i.e. linking non-PIC onject to PIC leads to non-PIC
binary.
I don't think it makes sense to support mixed binaries because I see no benefit
in that.
With hack to lto-wrapper:
Index: lto-wrapper.c
===================================================================
--- lto-wrapper.c (revision 249928)
+++ lto-wrapper.c (working copy)
@@ -238,10 +238,12 @@ merge_and_complain (struct cl_decoded_op
case OPT_fdiagnostics_show_option:
case OPT_fdiagnostics_show_location_:
case OPT_fshow_column:
+#if 0
case OPT_fPIC:
case OPT_fpic:
case OPT_fPIE:
case OPT_fpie:
+#endif
case OPT_fcommon:
case OPT_fexceptions:
case OPT_fnon_call_exceptions:
@@ -501,10 +503,12 @@ append_compiler_options (obstack *argv_o
case OPT_fdiagnostics_show_option:
case OPT_fdiagnostics_show_location_:
case OPT_fshow_column:
+#if 0
case OPT_fPIC:
case OPT_fpic:
case OPT_fPIE:
case OPT_fpie:
+#endif
case OPT_fcommon:
case OPT_fexceptions:
case OPT_fnon_call_exceptions:
I now get:
$ perf_4.3 stat ./xgcc -B ./ -O2 -S ~/combine.ii
Performance counter stats for './xgcc -B ./ -O2 -S /aux/hubicka/combine.ii':
5664.950671 task-clock (msec) # 0.998 CPUs utilized
581 context-switches # 0.103 K/sec
5 cpu-migrations # 0.001 K/sec
45,008 page-faults # 0.008 M/sec
16,882,004,890 cycles # 2.980 GHz
2,818,057,410 stalled-cycles-frontend # 16.69% frontend cycles
idle
5,462,286,464 stalled-cycles-backend # 32.36% backend cycles
idle
13,279,784,844 instructions # 0.79 insns per cycle
# 0.41 stalled cycles per
insn
2,919,823,112 branches # 515.419 M/sec
141,311,318 branch-misses # 4.84% of all branches
5.674328322 seconds time elapsed
Which is nice improvement over non-LTO binary.
