https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119
Bug ID: 69119
Summary: More fun with LTO on arm
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: tulipawn at gmail dot com
Target Milestone: ---
I've found a couple of `-flto -ffat-lto-objects` problems that happen on armv7
but not on x86 using the same gcc version. Not using -flto on arm makes the
issues go away.
**1**. https://github.com/jemalloc/jemalloc/issues/313
All tests pass on x86 with lto enabled. Should I open a new gcc issue?
**2**. Trying to link the rust compiler's stdlib with -flto and -fPIC among
CFLAGS ends like this:
rustc:
arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libstd
In function ‘memset’,
inlined from ‘je_malloc’ at
/tmp/rustc-nightly/src/jemalloc/include/jemalloc/internal/tcache.h:345:6:
/usr/include/arm-linux-gnueabihf/bits/string3.h:81:7: warning: call to
‘__warn_memset_zero_len’ declared with attribute warning: memset used with
constant zero length parameter; this could be due to transposed parameters
__warn_memset_zero_len ();
^
/usr/bin/ld.bfd.real: error: /tmp/cczYIjMC.ltrans0.ltrans.o: requires
unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-L"
"/tmp/rustc-nightly/arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib"
"arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/std-ca1c970e.0.o"
"-o"
"arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/libstd-ca1c970e.so"
"arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/std-ca1c970e.metadata.o"
"-Wl,-O1" "-nodefaultlibs" "-L" "arm-unknown-linux-gnueabihf/rt" "-L"
"/usr/lib/llvm-3.6/lib" "-L"
"/tmp/rustc-nightly/arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib"
"-Wl,-Bstatic" "-Wl,--whole-archive" "-l" "backtrace" "-Wl,--no-whole-archive"
"-Wl,-Bdynamic" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/libcollections-ca1c970e.rlib" "-Wl,--no-whole-archive"
"-Wl,--whole-archive" "/tmp/rustc.K1iwqkGsmEEU/liballoc-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/librustc_unicode-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/liballoc_jemalloc-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/liblibc-ca1c970e.rlib" "-Wl,--no-whole-archive"
"-Wl,--whole-archive" "/tmp/rustc.K1iwqkGsmEEU/librand-ca1c970e.rlib"
"-Wl,--no-whole-archive" "-Wl,--whole-archive"
"/tmp/rustc.K1iwqkGsmEEU/libcore-ca1c970e.rlib" "-Wl,--no-whole-archive" "-l"
"pthread" "-l" "c" "-l" "m" "-l" "rt" "-shared" "-l" "compiler-rt"
Again, the same lto build succeeds on x86 whereas a non-lto one finishes on
arm.
