On 02/27/2015 05:11 AM, Uros Bizjak wrote: > On Wed, Feb 25, 2015 at 8:18 PM, Richard Henderson <r...@redhat.com> wrote: >> On 02/25/2015 09:02 AM, Uros Bizjak wrote: >>> The patch was tested on alpha-linux-gnu and alphaev68-linux-gnu for >>> all default languages plus obj-c++ and go. >>> >>> OK for mainline? >> >> Ok. Thanks. > > Unfortunately, while "normal" bootstrap works OK with alpha-linux-gnu > and alphaev68-linux-gnu, the bootstrap still fails when configured > --with-build-config=bootstrap-lto: > > libbackend.a(tree-data-ref.o): In function `non_affine_dependence_relation': > /space/uros/gcc-build-profiled/gcc/../../gcc-svn/trunk/gcc/tree-data-ref.c:1661:(.text+0x1b8): > relocation truncated to fit: GPREL16 against symbol `dump_file' > defined in .sbss section in libbackend.a(dumpfile.o)
Interesting. And using bootstrap-lto works with --no-relax? I don't believe I've ever tried it... > Also reported is build failure on debian [1], where bootstrap dies > with ELF_LITERAL truncation: > > libbackend.a(tree-vect-generic.o): In function `gimple_statement_structure': > /«PKGBUILDDIR»/build/gcc/../../src/gcc/gimple.h:1572:(.text+0x2f4): > relocation truncated to fit: ELF_LITERAL against `.text' I strongly suspect this is something else. Since the error message still includes ELF_LITERAL, I can't imagine that relaxation is involved at all. This kind of error message is typically associated with object files that contain more than 8k unique got references, i.e. they exceed the 64k addressable got subsegment available to each input object file. Generally I see this error when projects do "ld -r" to combine all of the object files before final link. At which point I have to shrug and say "don't do that". But I could imagine that LTO could have the same net effect on Alpha, if we create too few partitions (and thus too few intermedate object files) and somehow had too many symbol references that remain "non-local", i.e. aren't emitted as GPRELHIGH+GPRELLOW pairs at compile-time. Of course, I would also expect that LTO would allow the compiler to see that 99% of all symbols in the application are local, and thus avoid using LITERAL relocations in the first place. The fact that we've got a LITERAL relocation against ".text" here is particularly suspicious. It would be illuminating to examine the intermediate object files in both cases. I'll start my system doing a build, but I expect it'll take a few days. r~
