[Patch,AVR] Was/Fix: error linking lto1 for target avr

Georg-Johann Lay avr@gjlay.de
Tue Dec 6 13:25:00 GMT 2011


Denis Chertykov wrote:
> 2011/11/29 Georg-Johann:
>> Ian Lance Taylor wrote:
>>> Georg-Johann Lay:
>>>
>>>> So if a frontend can define address spaces and it is a generic feature, the
>>>> question is how to get the name of an address space in a generic, language
>>>> independent way.
>>> We could decide that all frontends that use address spaces must define a
>>> printable name for each address space.  That would mean changing the
>>> middle-end address space interface to give a name to each address space.
>>> The current middle-end address space interface does not require that
>>> address spaces have a name.  I was not involved in the addition of
>>> address spaces to gcc, and I don't know why they followed the path they
>>> did.
>>>
>>> Ian
>> Presumably they chose that approach to keep it simple or it is even a
>> performance issue to move the name around.
>>
>> I attached a patch but I fail to find the right configure options for
>> gcc/binutils as the testsuite complains
>>
>> ./avr/bin/ld: bad -plugin option
>>
>> Configured gcc with --enable-lto and binutils 2.21 with --enable-plugin.
>>
>> Maybe the patch can be pre-approved so that the others can proceed with their work?
> 
> Better to complete this work.
> 
> Denis.

Finally, I could get LTO to work. Problem was in bad libdl.

The patch is unchanged:

http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02574.html

Diffs in testresults are:

> FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
> FAIL: gcc.c-torture/execute/builtins/memmove-chk.c compilation,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
> FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c compilation,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
> FAIL: gcc.c-torture/execute/builtins/memset-chk.c compilation,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects

Problem is non-aligned LTO stuff like

/home/georg/install/avr/bin/ld: Warning: alignment 1 of symbol `buf5' in
/tmp/ccAMUQqq.ltrans1.ltrans.o is smaller than 16 in /tmp/ccehY2eq.o.ironly
/home/georg/install/avr/bin/ld: Warning: alignment 1 of symbol `buf7' in
/tmp/ccAMUQqq.ltrans1.ltrans.o is smaller than 16 in /tmp/ccehY2eq.o.ironly
/home/georg/install/avr/bin/ld: Warning: alignment 1 of symbol `buf1' in
/tmp/ccAMUQqq.ltrans1.ltrans.o is smaller than 16 in /tmp/ccehY2eq.o.ironly
/home/georg/install/avr/bin/ld: Warning: alignment 1 of symbol `chk_calls' in
/tmp/ccAMUQqq.ltrans1.ltrans.o is smaller than 2 in /tmp/cc9w5uuC.o.ironly
/home/georg/install/avr/bin/ld: Warning: alignment 1 of symbol
`memcpy_disallowed' in /tmp/ccAMUQqq.ltrans1.ltrans.o is smaller than 2 in
/tmp/cc9w5uuC.o.ironly

> FAIL: gcc.c-torture/execute/980709-1.c compilation,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects

Bug in avr-libc using RJMP where not appropriate leading to

/home/georg/install/gcc-4.7/lib/gcc/avr/4.7.0/../../../../avr/lib/avr51/libc.a(log.o):../../../../../source/avr-libc-1.7.1/libm/fplib/log.S:96:
relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined
in .text section in
/home/georg/build/gcc-trunk-avr/gcc/avr51/libgcc.a(_addsub_sf.o)

> FAIL: gcc.c-torture/execute/simd-1.c compilation,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)

reload fail because data (vector) too big: internal compiler error: in
find_valid_class, at reload.c:707

> FAIL: gcc.dg/visibility-d.c scan-not-hidden

Problems with visibility pragma.

> FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_1.o assemble, -O0 -flto
-flto-partition=none -fuse-linker-plugin
> FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_1.o assemble, -O2 -flto
-flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
> FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_1.o assemble, -O0 -flto
-flto-partition=1to1 -fno-use-linker-plugin
> FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_1.o assemble, -O2 -flto
-flto-partition=1to1 -fno-use-linker-plugin
> FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_1.o assemble, -O0 -flto
-fuse-linker-plugin -fno-fat-lto-objects
> FAIL: gcc.dg/lto/20090218-2 c_lto_20090218-2_1.o assemble, -O2 -flto
-fuse-linker-plugin

Bad test case (use long instead of site_t)

> FAIL: gcc.dg/lto/20091013-1 c_lto_20091013-1_1.o assemble, -fPIC -r -nostdlib
-flto
> FAIL: gcc.dg/lto/20091013-1 c_lto_20091013-1_2.o assemble, -fPIC -r -nostdlib
-flto
> FAIL: gcc.dg/lto/20091013-1 c_lto_20091013-1_1.o assemble, -fPIC -r -nostdlib
-O2 -flto
> FAIL: gcc.dg/lto/20091013-1 c_lto_20091013-1_2.o assemble, -fPIC -r -nostdlib
-O2 -flto

Bad test case: Assumes sizeof(long) == sizeof (void*)

> FAIL: gcc.dg/lto/ipareference2
c_lto_ipareference2_0.o-c_lto_ipareference2_1.o link,  -O1 -flto
-flto-partition=1to1 -fwhole-program

Warning: alignment 1 of symbol `e' in /tmp/ccXmAeaF.ltrans1.ltrans.o is smaller
than 2 in c_lto_ipareference2_0.o.ironly

> FAIL: gcc.dg/lto/trans-mem-1 c_lto_trans-mem-1_0.o-c_lto_trans-mem-1_1.o
link, -flto -fgnu-tm

Bad test case: Assumes transactional memory is available.

> FAIL: gcc.dg/torture/fp-int-convert-double.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
> FAIL: gcc.dg/torture/fp-int-convert-float.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
> FAIL: gcc.dg/torture/fp-int-convert-long-double.c  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test

Bad test cases: Assume TImode is available.

> FAIL: gcc.dg/torture/pta-ptrarith-3.c  -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test

Known bug: PR50063/PR49330

> FAIL: gcc.dg/torture/vec-cvt-1.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)

Again, wrong LTO alignment

> FAIL: gcc.dg/torture/stackalign/builtin-apply-2.c  -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test

Testcase/builtin_apply have never been adapted for AVR


So the new FAILs are because the non-LTO -> LTO transition, not because of the
patch to review.

Ok to install?

Johann



More information about the Gcc-patches mailing list