libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib -I.. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14 -I/usr/include -Wall -W -pedantic -march=native -O3 -pipe -c /tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib/pair.c -fPIC -DPIC -o .libs/pair.o /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib -I.. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14 -I/usr/include -Wall -W -pedantic -march=native -O3 -pipe -c -o utf8_double.lo /tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib/utf8_double.c libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib -I.. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14 -I/usr/include -Wall -W -pedantic -march=native -O3 -pipe -c /tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib/unicodemap.c -fPIC -DPIC -o .libs/unicodemap.o libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib -I.. -I/tmp/portage/app-i18n/enca-1.14/work/enca-1.14 -I/usr/include -Wall -W -pedantic -march=native -O3 -pipe -c /tmp/portage/app-i18n/enca-1.14/work/enca-1.14/lib/utf8_double.c -fPIC -DPIC -o .libs/utf8_double.o /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -W -pedantic -march=native -O3 -pipe -version-info 5:1:5 -Wl,--as-needed -L/usr/lib -o libenca.la -rpath /usr/lib64 common.lo ctype.lo enca.lo encnames.lo filters.lo guess.lo lang.lo lang_be.lo lang_bg.lo lang_cs.lo lang_et.lo lang_hr.lo lang_hu.lo lang_lt.lo lang_lv.lo lang_pl.lo lang_ru.lo lang_sk.lo lang_sl.lo lang_uk.lo lang_zh.lo multibyte.lo pair.lo unicodemap.lo utf8_double.lo -lm libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC .libs/common.o .libs/ctype.o .libs/enca.o .libs/encnames.o .libs/filters.o .libs/guess.o .libs/lang.o .libs/lang_be.o .libs/lang_bg.o .libs/lang_cs.o .libs/lang_et.o .libs/lang_hr.o .libs/lang_hu.o .libs/lang_lt.o .libs/lang_lv.o .libs/lang_pl.o .libs/lang_ru.o .libs/lang_sk.o .libs/lang_sl.o .libs/lang_uk.o .libs/lang_zh.o .libs/multibyte.o .libs/pair.o .libs/unicodemap.o .libs/utf8_double.o -Wl,--as-needed -L/usr/lib -lm -march=native -O3 -Wl,-soname -Wl,libenca.so.0 -o .libs/libenca.so.0.5.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: .libs/multibyte.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC .libs/multibyte.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:448: recipe for target 'libenca.la' failed make[2]: *** [libenca.la] Error 1 make[2]: Leaving directory '/tmp/portage/app-i18n/enca-1.14/work/enca-1.14_build/lib' Makefile:540: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/tmp/portage/app-i18n/enca-1.14/work/enca-1.14_build' Makefile:403: recipe for target 'all' failed make: *** [all] Error 2 * ERROR: app-i18n/enca-1.14::gentoo failed (compile phase): * emake failed * Reproducible: Always falco ~ # emerge --info Portage 2.2.8-r1 (default/linux/amd64/13.0/desktop/kde/systemd, gcc-4.8.2, glibc-2.18-r1, 3.13.2 x86_64) ================================================================= System uname: Linux-3.13.2-x86_64-Intel-R-_Core-TM-_i5-4200U_CPU_@_1.60GHz-with-gentoo-2.2 KiB Mem: 3964608 total, 1743588 free KiB Swap: 0 total, 0 free Timestamp of tree: Thu, 13 Feb 2014 21:00:01 +0000 ld ld di GNU (GNU Binutils) 2.24 app-shells/bash: 4.2_p45-r1 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.6, 3.3.3 dev-util/cmake: 2.8.12.2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.4, 1.14.1 sys-devel/binutils: 2.24-r2 sys-devel/gcc: 4.7.3-r1, 4.8.2-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.18-r1
1) Please attach the entire build log to this bug report. 2) Please post your *entire* `emerge --info app-i18n/enca' output in a comment.
Created attachment 370708 [details] emerge --info app-i18n/enca
Created attachment 370710 [details] /tmp/portage/app-i18n/enca-1.14/temp/build.log
*** Bug 511008 has been marked as a duplicate of this bug. ***
Strange, enca compiles and installs fine for me on amd64 and gcc 4.8.2. Can you try the latest version in tree?
app-i18n/enca-1.14-r1 emerges fine
Argh. The bug was hit on another ~amd64 box. It's still there with a fresh sync as of today and using app-i18n/enca-1.14-r1 It works fine on my main computer, which is rather similar (~amd64). They both use gcc 4.8.2-r1. I'm thriving to find the difference between those two computers.
i would try an 'emerge -e', but that brings the whole system, 570 packages, including stuff like qt/kde which i really wonder why they appear here.
Switching from -O3 to -O2 fixed this for me. Perhaps the ebuild should filter CFLAGS?
@craig : well found ! Indeed, on my main computer where i have no problem i use -O2, and on my laptop where this bug comes from, i have -O3
May I ask you to attach 'work/enca-1.14_build/config.log' as well? It's interesting to compare good and bad 'config.log's on a box with this bug.
Mm.. interestingly, i can emerge app-i18n/enca-1.14-r1, even with -O3 (tree synced today). The major difference with my previous attempts is probably that i've switched to gcc-4.9 since then. I will re-open if i have any more information.
It still fails. The workaround of using -O2 instead of -O3 still works. There's no work/enca-1.14_build/config.log but i guess work/enca-1.14-abi_x86_64.amd64/config.log is what you want
(In reply to Thomas Capricelli from comment #13) > It still fails. The workaround of using -O2 instead of -O3 still works. > > There's no work/enca-1.14_build/config.log > but i guess work/enca-1.14-abi_x86_64.amd64/config.log is what you want Yeah, it was switched to multilib since. Please, attach it. And 1.14-r1 fail as well for you, right?
Created attachment 380808 [details] work/enca-1.14-abi_x86_64.amd64/config.log Here it is. The laptop crashed for another reason (kde) and it delayed this upload. This is actually app-i18n/enca-1.14-r1, since the beginning.
Aha, config.log revealed difference in environments: your gcc has such bits: > --with-cloog --disable-isl-version-check while mine doen't: > --without-cloog
er.. yes. I have no clue about this though. I haven't made anything with respect to this. My CFLAGS are quite common: CFLAGS="-march=native -pipe -O3"
Hi, I've also hit this very issue. My cflags: -O3 -pipe -march=native. Removing the -march=native let it to be built. The cpu is i7-4702MQ and gcc 4.8.3.
Just encountered this problem while installing fresh Gentoo, with version app-i18n/enca-1.14-r2 I got in CFLAGS at least -O3 and -march=core-avx2 and GCC 4.8.4. Workaround with setting optimisation lvl to -O2 helped. It seems to me that it's triggered if both -march=core-avx2 and -O3 are used (-march=native for i5-4200U and i7-4702 is core-avx2).
Would setting optimisation lvl to -O2 helped suffice as a fix here?
(In reply to Ian Delaney from comment #20) > Would setting optimisation lvl to -O2 helped suffice as a fix here? Some stats: - works: CC=gcc-4.9.2 CFLAGS="-O3 -march=core-avx2" - works: CC=gcc-5.1.0 CFLAGS="-O3 -march=core-avx2" - fails: CC=gcc-4.8.4 CFLAGS="-O3 -march=core-avx2" It would make sense to downgrade to -O2 only on gcc-4.8. I'm tracking down to exact optimization path breaking it.
(In reply to Sergei Trofimovich from comment #21) > (In reply to Ian Delaney from comment #20) > > Would setting optimisation lvl to -O2 helped suffice as a fix here? > > Some stats: > - works: CC=gcc-4.9.2 CFLAGS="-O3 -march=core-avx2" > - works: CC=gcc-5.1.0 CFLAGS="-O3 -march=core-avx2" > - fails: CC=gcc-4.8.4 CFLAGS="-O3 -march=core-avx2" > > It would make sense to downgrade to -O2 only on gcc-4.8. > I'm tracking down to exact optimization path breaking it. This code happens to be valid C (compilable): static int f(int v); int g(int v) { return f(v); } but not linkable as a call to 'f' has odd relocation type. I think gcc-4.8 loses 'static' class in some weird cases. Investigating more.
Pushed workaround as: > 29 May 2015; Sergei Trofimovich <slyfox@gentoo.org> > +files/enca-1.14-gcc4.8-avx-bug.patch, enca-1.14-r2.ebuild: > Workaround gcc-4.8 AVX bug #501386 by Thomas Capricelli and friends. Please reopen if it still fails in other ways. I'll try to distill it down to small test and look if it's fixed in recent GCC. Thanks!
(In reply to Sergei Trofimovich from comment #21) > (In reply to Ian Delaney from comment #20) > > Would setting optimisation lvl to -O2 helped suffice as a fix here? > > Some stats: > - works: CC=gcc-4.9.2 CFLAGS="-O3 -march=core-avx2" > - works: CC=gcc-5.1.0 CFLAGS="-O3 -march=core-avx2" > - fails: CC=gcc-4.8.4 CFLAGS="-O3 -march=core-avx2" > > It would make sense to downgrade to -O2 only on gcc-4.8. > I'm tracking down to exact optimization path breaking it. Thank you very much for the analysis. This is also not reproducible on gcc-4.7.4.
Best I could find about this GCC bug is the following reproducer: //bug.c void f (int a); static const int PERMS[4] = { 0, 0, 0, 0, }; int bug (int size, int r) { int max = 0; int i; int j; for (i = 0; i < 4; ++i) { if (size) max = 1; f (PERMS[i]); } for (j = 0; j < max; ++j) r |= PERMS[i&1]; return r; } With the following gcc options it generates incorrect object file: gcc-4.8.5 -Wall -W -O3 -march=core-avx2 -fcse-follow-jumps -fgcse -fguess-branch-probability -fif-conversion -ftree-ch -ftree-loop-ivcanon -ftree-loop-optimize -ftree-vectorize -fno-gcse-after-reload -fno-inline-functions -fno-ipa-cp-clone -fno-predictive-commoning -fno-tree-loop-distribute-patterns -fno-tree-partial-pre -ftree-vectorize -fno-unswitch-loops -fno-vect-cost-model -fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-asynchronous-unwind-tables -fno-branch-count-reg -fno-caller-saves -fno-combine-stack-adjustments -fno-common -fno-compare-elim -fno-cprop-registers -fno-crossjumping -fno-dce -fno-defer-pop -fno-delete-null-pointer-checks -fno-devirtualize -fno-dse -fno-early-inlining -fno-expensive-optimizations -fno-forward-propagate -fno-gcse-lm -fno-hoist-adjacent-loads -fno-if-conversion2 -fno-inline -fno-inline-atomics -fno-inline-functions-called-once -fno-inline-small-functions -fno-ipa-cp -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-reference -fno-ipa-sra -fno-ira-hoist-pressure -fno-ivopts -fno-jump-tables -fno-math-errno -fno-merge-constants -fno-move-loop-invariants -fno-optimize-register-move -fno-optimize-sibling-calls -fno-optimize-strlen -fno-peephole -fno-peephole2 -fno-prefetch-loop-arrays -fno-regmove -fno-rename-registers -fno-reorder-blocks -fno-reorder-functions -fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock -fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec -fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep -fno-schedule-insns2 -fno-short-enums -fno-shrink-wrap -fno-signed-zeros -fno-split-ivs-in-unroller -fno-split-wide-types -fno-strict-aliasing -fno-thread-jumps -fno-toplevel-reorder -fno-trapping-math -fno-tree-bit-ccp -fno-tree-builtin-call-dce -fno-tree-ccp -fno-tree-coalesce-vars -ftree-copy-prop -ftree-copyrename -ftree-cselim -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-forwprop -fno-tree-fre -fno-tree-loop-if-convert -fno-tree-loop-im -fno-tree-phiprop -fno-tree-pre -fno-tree-pta -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize -fno-tree-slsr -fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge -fno-tree-ter -fno-tree-vect-loop-version -fno-tree-vrp -fno-unit-at-a-time -fno-web -fno-var-tracking -fno-var-tracking-assignments -S bug.c -fPIC -o bug.S It disables most available optimisations. Invalid asm code here is: vpgatherdd %ymm5, PERMS(,%ymm2,4), %ymm3 where PERMS is a local (absolute) label. It's incorrect as we generate PIC code. There is no relative addressing in this instruction. gcc-4.9 gets it right: leaq PERMS(%rip), %r15 vpgatherdd %ymm6, (%r15,%ymm1,4), %ymm4 Best I could find as an intentional fix in gcc tree is tightened constraint around gather instructions: https://github.com/gcc-mirror/gcc/commit/1e662e65158f08193cc0337064e775d4daf87c3d
Created attachment 447884 [details] gcc-bug.tar.gz gcc-bug.tar.gz - a tiny reproducer I used to trim sample down something manageable.
(In reply to Sergei Trofimovich from comment #26) > Created attachment 447884 [details] > gcc-bug.tar.gz > > gcc-bug.tar.gz - a tiny reproducer I used to trim sample down something > manageable. Verified by bisection overnight. https://github.com/gcc-mirror/gcc/commit/1e662e65158f08193cc0337064e775d4daf87c3d indeed fixed the issue. $ ~/dev/git/gcc:git bisect good 1e662e65158f08193cc0337064e775d4daf87c3d is the first bad commit commit 1e662e65158f08193cc0337064e775d4daf87c3d Author: uros <uros@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Sat Nov 2 11:32:53 2013 +0000 * config/i386/constraints.md (Ts, Tv): New address constrains. * config/i386/i386.md (*lea<mode>, *<mode>_<bndcheck>): Use Ts constraint for address_no_seg_operand. * config/i386/sse.md (*avx512pf_gatherpf<mode>_mask) (*avx512pf_gatherpf<mode>, *avx512pf_scatterpf<mode>_mask) (*avx512pf_scatterpf<mode>, *avx2_gathersi<mode>) (*avx2_gathersi<mode>_2, *avx2_gatherdi<mode>, *avx2_gatherdi<mode>_2) (*avx2_gatherdi<mode>_3, *avx2_gatherdi<mode>_4) (*avx512f_gathersi<mode>, *avx512f_gathersi<mode>_2) (*avx512f_gatherdi<mode>, *avx512f_gatherdi<mode>_2) (*avx512f_scattersi<mode> *avx512f_scatterdi<mode>): Use Tv constraint for vsib_address_operand. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204317 138bc75d-0d04-0410-961f-82ee72b054a4 :040000 040000 502912ea1651b6fdd1573460631df510543baa6c 55cdb44531ea2abdf00a088ef4d994f4ffee735e M gcc
Created attachment 447948 [details] gcc-bisect.log
