2011/12/6 Georg-Johann Lay <a...@gjlay.de>: > 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?
Ok. Denis.
