Re: LTO on newlib targets w/o Gold
On 01/02/2011 02:33, Joel Sherrill wrote:
> Hi,
>
> There are ~100 failures on each *-rtems* target
> in the latest test runs when various lto related
> flags are on. The symbols in questions are in the
> RTEMS libraries which are picked up via the
> -B... argument. Other symbols from the same
> library are resolved.
These have all cropped up since -fuse-linker-plugin became the default.
> Should LTO work with a target not using gold?
Yes, it should, but some work is needed at the binutils end. I am testing
the attached two patches at the moment; the idea is to have fully-debugged
support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes
out.
cheers,
DaveK
--
Apologies if dup - ENOPATCH first time I hit send.
>From 6cad541c1902edf5ceb483a20666a90be954e3d4 Mon Sep 17 00:00:00 2001
From: Dave Korn
Date: Mon, 31 Jan 2011 03:26:05 +
Subject: [PATCH] ld/ChangeLog:
2011-01-29 Dave Korn <...
* ldlang.h (lang_input_statement_type): Add new 'claim_archive' flag.
* ldmain.c (add_archive_element): Set it if the member is claimed.
* ldlang.c (new_afile): Initialise claim_archive and claimed members.
(find_replacements_insert_point): New helper function.
(lang_process): After adding and opening replacement files passed
from plugin, splice them into correct place in statement list and
file chains to preserve critical link order.
(lang_list_insert_after): New helper function.
(lang_list_remove_tail): Likewise.
---
ld/ldlang.c | 134 +++
ld/ldlang.h |3 +
ld/ldmain.c |1 +
3 files changed, 129 insertions(+), 9 deletions(-)
diff --git a/ld/ldlang.c b/ld/ldlang.c
index 7ffe760..53d2901 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -85,6 +85,11 @@ static void print_statement_list (lang_statement_union_type *,
static void print_statements (void);
static void print_input_section (asection *, bfd_boolean);
static bfd_boolean lang_one_common (struct bfd_link_hash_entry *, void *);
+static void lang_list_insert_after (lang_statement_list_type *destlist,
+lang_statement_list_type *srclist,
+lang_statement_union_type **field);
+static void lang_list_remove_tail (lang_statement_list_type *destlist,
+ lang_statement_list_type *origlist);
static void lang_record_phdrs (void);
static void lang_do_version_exports_section (void);
static void lang_finalize_version_expr_head
@@ -1126,6 +1131,8 @@ new_afile (const char *name,
p->whole_archive = whole_archive;
p->loaded = FALSE;
p->missing_file = FALSE;
+ p->claimed = FALSE;
+ p->claim_archive = FALSE;
lang_statement_append (&input_file_chain,
(lang_statement_union_type *) p,
@@ -6394,6 +6401,38 @@ lang_relax_sections (bfd_boolean need_layout)
}
}
+/* Find the insert point for the plugin's replacement files. We
+ place them after the first claimed real object file, or if the
+ first claimed object is an archive member, after the last real
+ object file immediately preceding the archive. In the event
+ no objects have been claimed at all, we return the first dummy
+ object file on the list as the insert point; that works, but
+ the callee must be careful when relinking the file_chain as it
+ is not actually on that chain, only the statement_list and the
+ input_file list; in that case, the replacement files must be
+ inserted at the head of the file_chain. */
+
+static lang_input_statement_type *
+find_replacements_insert_point (void)
+{
+ lang_input_statement_type *claim1, *lastobject;
+ lastobject = &input_file_chain.head->input_statement;
+ for (claim1 = &file_chain.head->input_statement;
+ claim1 != NULL;
+ claim1 = &claim1->next->input_statement)
+{
+ if (claim1->claimed)
+ return claim1->claim_archive ? lastobject : claim1;
+ /* Update lastobject if this is a real object file. */
+ if (claim1->the_bfd && (claim1->the_bfd->my_archive == NULL))
+ lastobject = claim1;
+}
+ /* No files were claimed by the plugin. Choose the last object
+ file found on the list (maybe the first, dummy entry) as the
+ insert point. */
+ return lastobject;
+}
+
void
lang_process (void)
{
@@ -6420,21 +6459,54 @@ lang_process (void)
open_input_bfds (statement_list.head, FALSE);
#ifdef ENABLE_PLUGINS
+ if (plugin_active_plugins_p ())
{
- union lang_statement_union **listend;
+ lang_statement_list_type added;
+ lang_statement_list_type files, inputfiles;
/* Now all files are read, let the plugin(s) decide if there
are any more to be added to the link before we call the
- emulation's after_open hook. */
- listend = statement_list.tail;
- ASSERT (!*listend);
+ emulation's after_open hook. We create a private list of
+ input statements for this purpose, which we will eventually
+ insert into the global statment list after the first claimed
+ file. */
+ added = *stat_ptr;
+ /* We need to manipulat
Re: GCC 4.3.5 Status Report (2010-05-22)
On Mon, Jan 31, 2011 at 6:56 PM, Joseph S. Myers wrote: > On Mon, 31 Jan 2011, NightStrike wrote: > >> On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther >> wrote: >> > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song >> > wrote: >> >> It's very simple (only for trunk, although it maybe more useful for >> >> branches): >> > >> > Or simply put Last-Changed-Date into DATESTAMP, not the >> > current date. >> >> This has other benefits as well, since it means that the date in the >> gcc version string becomes the date of the last actual revision, >> instead of the date that the datestamp change is committed. > > Not in the case where you have no datestamp changes for a month, say, then > some other change is committed, but a new datestamp change hasn't yet been > committed after that other change; then you have, for a limited period, a > compiler with a datestamp value long before the last commit. (That's the > main case I can think of for not making snapshots if only DATESTAMP has > changed, rather than the simpler approach of omitting some DATESTAMP > updates and not making snapshots if nothing at all has changed.) The DATESTAMP change could also be in a post-commit hook (doing nothing if the date didn't change, of course). No idea whether this is technically possible of course. Richard.
Re: LTO on newlib targets w/o Gold
On Tue, Feb 1, 2011 at 11:54 AM, Dave Korn wrote: > On 01/02/2011 02:33, Joel Sherrill wrote: >> Hi, >> >> There are ~100 failures on each *-rtems* target >> in the latest test runs when various lto related >> flags are on. The symbols in questions are in the >> RTEMS libraries which are picked up via the >> -B... argument. Other symbols from the same >> library are resolved. > > These have all cropped up since -fuse-linker-plugin became the default. But it should not be the default for your build unless you have either gold or recent binutils. You can verify this by looking at the collect2 invocations and see if there are -plugin args. Richard. >> Should LTO work with a target not using gold? > > Yes, it should, but some work is needed at the binutils end. I am testing > the attached two patches at the moment; the idea is to have fully-debugged > support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes > out. > > cheers, > DaveK > -- > Apologies if dup - ENOPATCH first time I hit send. > > >
Re: Bugzilla permissions
>> Could someone with the powers please modify my permissions to the above? > > I will do that if a gcc maintainer vouches for you. For the record, this situation has now been resolved and I can edit the bugs as requested. Many thanks, Tony
Re: GCC 4.3.5 Status Report (2010-05-22)
On Tue, Feb 1, 2011 at 5:31 AM, Richard Guenther wrote: > On Mon, Jan 31, 2011 at 6:56 PM, Joseph S. Myers > wrote: >> On Mon, 31 Jan 2011, NightStrike wrote: >> >>> On Mon, Jan 31, 2011 at 7:51 AM, Richard Guenther >>> wrote: >>> > On Mon, Jan 31, 2011 at 3:43 AM, Dongsheng Song >>> > wrote: >>> >> It's very simple (only for trunk, although it maybe more useful for >>> >> branches): >>> > >>> > Or simply put Last-Changed-Date into DATESTAMP, not the >>> > current date. >>> >>> This has other benefits as well, since it means that the date in the >>> gcc version string becomes the date of the last actual revision, >>> instead of the date that the datestamp change is committed. >> >> Not in the case where you have no datestamp changes for a month, say, then >> some other change is committed, but a new datestamp change hasn't yet been >> committed after that other change; then you have, for a limited period, a >> compiler with a datestamp value long before the last commit. (That's the >> main case I can think of for not making snapshots if only DATESTAMP has >> changed, rather than the simpler approach of omitting some DATESTAMP >> updates and not making snapshots if nothing at all has changed.) > > The DATESTAMP change could also be in a post-commit hook (doing > nothing if the date didn't change, of course). No idea whether this > is technically possible of course. > > Richard. > I can't find it right now, but I read something recently about using hooks to put revision numbers inside source controlled files.
Re: Devirtualization in gcc
On Jan 26, 2011, at 3:27 AM, Ian Lance Taylor wrote: > Black Bit writes: > >> Could someone tell me if the work described in this paper >> http://www.linuxsymposium.org/archives/GCC/Reprints-2006/namolaru-reprint.pdf >> was completed and is part of gcc?Thanks >> > > To the best of my knowledge the work has not yet become part of mainline > gcc. Perhaps the Haifa folks can correct me if I am wrong. The approach described in the paper resembles devirtualization optimizations Martin Jambor implemented as part of the IPA CP pass. AFAIK, the two implementations were different efforts. The implementation in current mainline does not define the lattice to track types as clear as the paper, but functionally it is very similar. We (CodeSourcery) have patches that refactor type propagation code in ipa-cp.c to clearly describe the type information lattice [*]. Having information represented as lattice is advantageous as it makes it easier to reuse devirtualization analysis in other optimization passes. [*] http://gcc.gnu.org/ml/gcc/2010-12/msg00461.html -- Maxim Kuvyrkov CodeSourcery +7-812-677-6839
Re: LTO on newlib targets w/o Gold
On 02/01/2011 04:54 AM, Dave Korn wrote: On 01/02/2011 02:33, Joel Sherrill wrote: Hi, There are ~100 failures on each *-rtems* target in the latest test runs when various lto related flags are on. The symbols in questions are in the RTEMS libraries which are picked up via the -B... argument. Other symbols from the same library are resolved. These have all cropped up since -fuse-linker-plugin became the default. Ahh. And I am using the heads of binutils, gcc, newlib, gdb, and rtems so it is getting enabled. Should LTO work with a target not using gold? Yes, it should, but some work is needed at the binutils end. I am testing the attached two patches at the moment; the idea is to have fully-debugged support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes out. There are still some rtems targets which need to finish from the last full build. But I will try your patches once that is done. If it is still broken, what do you need gathered up to have a test case? Thanks. cheers, DaveK -- Joel Sherrill, Ph.D. Director of Research& Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: GCC 4.3.5 Status Report (2010-05-22)
On Tue, Feb 1, 2011 at 18:31, Richard Guenther wrote: > > The DATESTAMP change could also be in a post-commit hook (doing > nothing if the date didn't change, of course). No idea whether this > is technically possible of course. > > Richard. > Yes, the post-commit hook can do this task. If we really want to do that, I can update the current post-commit hook script [1]. *) Get DATESTAMP for the current branch in the repository, e.g. $ svn cat svn://gcc.gnu.org/svn/gcc/trunk/gcc/DATESTAMP 20110201 $ svn cat svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch/gcc/DATESTAMP 20110201 ... *) Get the current DATESTAMP $ /bin/date +"%Y%m%d" 20110201 *) If the two DATESTAMP is equal, do nothing; otherwise update the DATESTAMP in the repository. [1] svn://gcc.gnu.org/svn/gcc/hooks/post-commit -- Dongsheng
Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Tue, 1 Feb 2011, Dongsheng Song wrote: >> The DATESTAMP change could also be in a post-commit hook (doing >> nothing if the date didn't change, of course). No idea whether >> this is technically possible of course. > Yes, the post-commit hook can do this task. > If we really want to do that, I can update the current post-commit > hook script [1]. I'd love to see that and will be happy to work on this with you, apply a patch, etc. Let's give others the chance to chime in, and if there are no objections within the next two days, let's proceed. Fair? Gerald
Re: LTO on newlib targets w/o Gold
On 01/02/2011 14:30, Joel Sherrill wrote: > On 02/01/2011 04:54 AM, Dave Korn wrote: >> On 01/02/2011 02:33, Joel Sherrill wrote: >>> Should LTO work with a target not using gold? >>Yes, it should, but some work is needed at the binutils end. I am >> testing >> the attached two patches at the moment; the idea is to have >> fully-debugged >> support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it >> comes out. >> > There are still some rtems targets which need to finish from the > last full build. But I will try your patches once that is done. > > If it is still broken, what do you need gathered up to have a test case? Depends exactly how it's broken. If it looks like a linker bug, the thing to do is re-run the failing command line with "-v -Wl,-v -Wl,--verbose --save-temps", and bundle up all the generated files along with a log of the build. That way I can re-run (and debug) the failing link using just a cross-binutils aimed at the target. cheers, DaveK
Re: LTO on newlib targets w/o Gold
On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote: > On 01/02/2011 02:33, Joel Sherrill wrote: >> Hi, >> >> There are ~100 failures on each *-rtems* target >> in the latest test runs when various lto related >> flags are on. The symbols in questions are in the >> RTEMS libraries which are picked up via the >> -B... argument. Other symbols from the same >> library are resolved. > > These have all cropped up since -fuse-linker-plugin became the default. > >> Should LTO work with a target not using gold? > > Yes, it should, but some work is needed at the binutils end. I am testing > the attached two patches at the moment; the idea is to have fully-debugged > support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes > out. > FWIW, your recan linker patch doesn't fix LTO 8, which is: http://sourceware.org/bugzilla/show_bug.cgi?id=12277 -- H.J.
Proper way to build GNAT cross compiler with gnattools
Hi, I'm trying (again) to work out how to build a GNAT cross compiler with no runtime, but with the tools. Firstly, I'd just like to ask, is this supposed to be possible? If it is possible, why is it so hard/impossible and why will nobody from AdaCore answer my questions regarding it? I'm wanting to start development on my kernel and would prefer not to use a hacky way to do it. I'm currently using binutils-2.21, newlib-1.19.0, gcc-4.5.2, latest mpfr, bmp, mpc and am trying to target arm-none-eabi to start with. I've firstly build binutils, then gcc C compiler, then newlib, now i'm trying to build C + Ada. I need the C stuff with newlib so I can build u-boot, but when I get to Ada, I don't need it at all. I'm configuring the second gcc build with: ../../../src/gcc-$GCC_VERSION/configure \ --prefix=$PREFIX \ --target=$1 \ $2 \ --enable-multilib \ --with-newlib \ --with-headers=../../../src/newlib-$NEWLIB_VERSION/newlib/libc/include \ --disable-nls \ --disable-shared \ --disable-threads \ --with-gnu-as \ --with-gnu-ld \ --enable-languages=c,ada \ --disable-libssp \ --disable-libada \ --with-gmp=$GCC_LIBS_PREFIX/gmp \ --with-mpfr=$GCC_LIBS_PREFIX/mpfr \ --with-mpc=$GCC_LIBS_PREFIX/mpc &> log.config.txt $1 is arm-none-eabi and $2 is the --enable-interworking passed as parameters to my build function. When I do a "make" it fails around here: make[2]: Leaving directory `/home/laguest/src/mine/tamp/thirdparty/build/arm-none-eabi/gcc2/gcc' mkdir -p -- ./gnattools Configuring in ./gnattools configure: creating cache ./config.cache checking for a BSD-compatible install... /usr/bin/install -c checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... arm-none-eabi checking whether ln -s works... yes checking for x86_64-unknown-linux-gnu-gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed configure: updating cache ./config.cache configure: creating ./config.status config.status: creating Makefile make[2]: Entering directory `/home/laguest/src/mine/tamp/thirdparty/build/arm-none-eabi/gcc2/gnattools' rm -rf ../gcc/ada/tools mkdir -p ../gcc/ada/tools (cd ../gcc/ada/tools; ln -s ../sdefault.adb ../snames.ads ../snames.adb .) touch ../gcc/stamp-tools # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ "CC=gcc" "CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes" "LDFLAGS=" "ADAFLAGS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-I. -I.. -I../.. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/config -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/../include -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc" "ADA_INCLUDES=-I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada" "exeext=" "fsrcdir=/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc" "srcdir=/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc" "GNATMAKE=gnatmake" "GNATLINK=gnatlink" "GNATBIND=gnatbind" "TOOLSCASE=cross" "LIBGNAT=" INCLUDES="" \ gnatmake-re gnatlink-re make[3]: Entering directory `/home/laguest/src/mine/tamp/thirdparty/build/arm-none-eabi/gcc2/gcc/ada/tools' gcc -c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC `echo -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` \ /home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada/link.c -o link.o gcc -c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC `echo -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` \ -I. -I.. -I../.. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/../include -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc \ /home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada/targext.c -o targext.o gnatmake -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada -u sdefault --GCC="gcc " gcc -c -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada sdefault.adb gnatmake -c -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.4.3/adalib/ -I. -I/home/laguest/src/mine/tamp/thirdparty/src/gcc-4.5.2/gcc/ada gnatmake --GCC="gcc -g -O2 -
Re: LTO on newlib targets w/o Gold
On 01/02/2011 17:15, H.J. Lu wrote: > On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote: >> On 01/02/2011 02:33, Joel Sherrill wrote: >>> Hi, >>> >>> There are ~100 failures on each *-rtems* target >>> in the latest test runs when various lto related >>> flags are on. The symbols in questions are in the >>> RTEMS libraries which are picked up via the >>> -B... argument. Other symbols from the same >>> library are resolved. >> These have all cropped up since -fuse-linker-plugin became the default. >> >>> Should LTO work with a target not using gold? >> Yes, it should, but some work is needed at the binutils end. I am testing >> the attached two patches at the moment; the idea is to have fully-debugged >> support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes >> out. >> > > FWIW, your recan linker patch doesn't fix LTO 8, which is: > > http://sourceware.org/bugzilla/show_bug.cgi?id=12277 It wasn't supposed to, we've been through this before. It needs both the link-order fix *and* the rescan-libs fix. The combined pair of patches I sent Joel (one of which is indeed that first patch, the second of which is for lib rescanning) *does* fix LTO 8 on i686/Linux, I tested it. cheers, DaveK
Re: Proper way to build GNAT cross compiler with gnattools
> I'm trying (again) to work out how to build a GNAT cross compiler with > no runtime, but with the tools. As explained in the documentation, you need to first build a native GNAT compiler with the same sources before building a GNAT cross compiler. Arno
Re: LTO on newlib targets w/o Gold
On Tue, Feb 1, 2011 at 9:52 AM, Dave Korn wrote:
> On 01/02/2011 17:15, H.J. Lu wrote:
>> On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote:
>>> On 01/02/2011 02:33, Joel Sherrill wrote:
Hi,
There are ~100 failures on each *-rtems* target
in the latest test runs when various lto related
flags are on. The symbols in questions are in the
RTEMS libraries which are picked up via the
-B... argument. Other symbols from the same
library are resolved.
>>> These have all cropped up since -fuse-linker-plugin became the default.
>>>
Should LTO work with a target not using gold?
>>> Yes, it should, but some work is needed at the binutils end. I am testing
>>> the attached two patches at the moment; the idea is to have fully-debugged
>>> support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it
>>> comes out.
>>>
>>
>> FWIW, your recan linker patch doesn't fix LTO 8, which is:
>>
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>
> It wasn't supposed to, we've been through this before. It needs both the
> link-order fix *and* the rescan-libs fix. The combined pair of patches I sent
> Joel (one of which is indeed that first patch, the second of which is for lib
> rescanning) *does* fix LTO 8 on i686/Linux, I tested it.
>
I applied 2 patches of yours, With gcc version 4.6.0 revision 169143, I got
/usr/gcc-4.6/bin/gcc
-B/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/
-L/usr/local/i686-linux/lib -L/usr/local/lib -L/lib -L/usr/lib -m32
-o tmpdir/lto-8.exe
-L/net/gnu-6/export/gnu/src/binutils/binutils/ld/testsuite/ld-plugin
-O2 -flto -fuse-linker-plugin tmpdir/lto-8b.o tmpdir/lto-8a.o
tmpdir/dummy.o
Executing on host: sh -c {/usr/gcc-4.6/bin/gcc
-B/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/
-L/usr/local/i686-linux/lib -L/usr/local/lib -L/lib -L/usr/lib -m32
-o tmpdir/lto-8.exe
-L/net/gnu-6/export/gnu/src/binutils/binutils/ld/testsuite/ld-plugin
-O2 -flto -fuse-linker-plugin tmpdir/lto-8b.o tmpdir/lto-8a.o
tmpdir/dummy.o 2>&1} /dev/null ld.tmp (timeout = 300)
/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/ld:
tmpdir/lto-8.exe: hidden symbol `bar' isn't defined
/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/ld: final
link failed: Bad value
collect2: ld returned 1 exit status
--
H.J.
Re: LTO on newlib targets w/o Gold
On 01/02/2011 18:01, H.J. Lu wrote:
>>> FWIW, your recan linker patch doesn't fix LTO 8, which is:
>>>
>>> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>> It wasn't supposed to, we've been through this before. It needs both the
>> link-order fix *and* the rescan-libs fix. The combined pair of patches I
>> sent
>> Joel (one of which is indeed that first patch, the second of which is for lib
>> rescanning) *does* fix LTO 8 on i686/Linux, I tested it.
>>
>
> I applied 2 patches of yours, With gcc version 4.6.0 revision 169143, I got
>
> /usr/gcc-4.6/bin/gcc
> -B/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/
> -L/usr/local/i686-linux/lib -L/usr/local/lib -L/lib -L/usr/lib -m32
> -o tmpdir/lto-8.exe
> -L/net/gnu-6/export/gnu/src/binutils/binutils/ld/testsuite/ld-plugin
> -O2 -flto -fuse-linker-plugin tmpdir/lto-8b.o tmpdir/lto-8a.o
> tmpdir/dummy.o
> Executing on host: sh -c {/usr/gcc-4.6/bin/gcc
> -B/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/
> -L/usr/local/i686-linux/lib -L/usr/local/lib -L/lib -L/usr/lib -m32
> -o tmpdir/lto-8.exe
> -L/net/gnu-6/export/gnu/src/binutils/binutils/ld/testsuite/ld-plugin
> -O2 -flto -fuse-linker-plugin tmpdir/lto-8b.o tmpdir/lto-8a.o
> tmpdir/dummy.o 2>&1} /dev/null ld.tmp (timeout = 300)
> /export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/ld:
> tmpdir/lto-8.exe: hidden symbol `bar' isn't defined
> /export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/ld: final
> link failed: Bad value
> collect2: ld returned 1 exit status
*facepalm* D'oh, sorry for the confusion. I got mixed up with LTO 2, which
is the missing -lm reference problem; it resolves that one. Sorry, this is
the left-over undefined symbols problem, that is going to need a further patch.
cheers,
DaveK
Re: LTO on newlib targets w/o Gold
On Tue, Feb 1, 2011 at 10:39 AM, Dave Korn wrote:
> On 01/02/2011 18:01, H.J. Lu wrote:
>
FWIW, your recan linker patch doesn't fix LTO 8, which is:
http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>>> It wasn't supposed to, we've been through this before. It needs both the
>>> link-order fix *and* the rescan-libs fix. The combined pair of patches I
>>> sent
>>> Joel (one of which is indeed that first patch, the second of which is for
>>> lib
>>> rescanning) *does* fix LTO 8 on i686/Linux, I tested it.
>>>
>>
>> I applied 2 patches of yours, With gcc version 4.6.0 revision 169143, I got
>>
>> /usr/gcc-4.6/bin/gcc
>> -B/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/
>> -L/usr/local/i686-linux/lib -L/usr/local/lib -L/lib -L/usr/lib -m32
>> -o tmpdir/lto-8.exe
>> -L/net/gnu-6/export/gnu/src/binutils/binutils/ld/testsuite/ld-plugin
>> -O2 -flto -fuse-linker-plugin tmpdir/lto-8b.o tmpdir/lto-8a.o
>> tmpdir/dummy.o
>> Executing on host: sh -c {/usr/gcc-4.6/bin/gcc
>> -B/export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/
>> -L/usr/local/i686-linux/lib -L/usr/local/lib -L/lib -L/usr/lib -m32
>> -o tmpdir/lto-8.exe
>> -L/net/gnu-6/export/gnu/src/binutils/binutils/ld/testsuite/ld-plugin
>> -O2 -flto -fuse-linker-plugin tmpdir/lto-8b.o tmpdir/lto-8a.o
>> tmpdir/dummy.o 2>&1} /dev/null ld.tmp (timeout = 300)
>> /export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/ld:
>> tmpdir/lto-8.exe: hidden symbol `bar' isn't defined
>> /export/build/gnu/binutils-lto/build-i686-linux/ld/tmpdir/ld/ld: final
>> link failed: Bad value
>> collect2: ld returned 1 exit status
>
> *facepalm* D'oh, sorry for the confusion. I got mixed up with LTO 2, which
> is the missing -lm reference problem; it resolves that one. Sorry, this is
> the left-over undefined symbols problem, that is going to need a further
> patch.
>
I opened:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=12456
--
H.J.
Re: Proper way to build GNAT cross compiler with gnattools
On Tue, 2011-02-01 at 18:57 +0100, Arnaud Charlet wrote: > > I'm trying (again) to work out how to build a GNAT cross compiler with > > no runtime, but with the tools. > > As explained in the documentation, you need to first build a native GNAT > compiler with the same sources before building a GNAT cross compiler. Ok, I can't find it. I'just grepped for cross and compi through gcc/ada/*.texi and there are references, but nothing that you state. Certainly not in the fsf 4.5.2 version of gnat. I also cannot see anything obvious in the gnat pro docs that I've managed to find online. Can you point me at least to the section which explains this? Thanks, Luke.
gcc-4.4-20110201 is now available
Snapshot gcc-4.4-20110201 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110201/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 169505 You'll find: gcc-4.4-20110201.tar.bz2 Complete GCC (includes all of below) MD5=50d0cfb9918b83dfee45e8e9dfa1f723 SHA1=3ee3d0c909892ad1ccfa5ee20e6d8c967e8b5662 gcc-core-4.4-20110201.tar.bz2C front end and core compiler MD5=c5153cb064ee5226cebf0352d2b6eee8 SHA1=4afd4159cb9f08d7be4d7bd29bfc7d60766453a1 gcc-ada-4.4-20110201.tar.bz2 Ada front end and runtime MD5=ed1b87e49608d3c5ebdbaae66698ea5c SHA1=73338a3be15220cea63ba773270e1a1bd3db0419 gcc-fortran-4.4-20110201.tar.bz2 Fortran front end and runtime MD5=8e13c086dd661758c4221892e860fcda SHA1=da7e2dad1e3f20261a2d83c23f9b9a6c5994ce3a gcc-g++-4.4-20110201.tar.bz2 C++ front end and runtime MD5=5279aeaa86a0e0429649f7fe77221c34 SHA1=a911890cdeef066c687e8794830be4c22f26740c gcc-go-4.4-20110201.tar.bz2 Go front end and runtime MD5=724f1cdd089b64eba9974f6b8a00fd11 SHA1=8e25c05ae37935cea29a0260431c6fbf3a6c2140 gcc-java-4.4-20110201.tar.bz2Java front end and runtime MD5=e45cbaefdb377f6de45f56386e4814f2 SHA1=f5262fcf860d06b7e31cce8e5e2a2a18a7cff17e gcc-objc-4.4-20110201.tar.bz2Objective-C front end and runtime MD5=b66e634df23dbbaf6a5fb0823be3511e SHA1=9b3c877160d6fa2152133d1f45214258c6ffa640 gcc-testsuite-4.4-20110201.tar.bz2 The GCC testsuite MD5=bfee18494578825698ce65ea9823d9c4 SHA1=e80a198628ee5899251fd46d712cafe84431a592 Diffs from 4.4-20110125 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Proposal: Improving patch tracking and review using Rietveld
On Jan 28, 2011, Diego Novillo wrote: > Technically, Rietveld solves the ENOPATCH problem because the patch is > *always* available at the URL produced in the patch message. Hi, Diego, I just got your e-mail with the patch. It didn't look that big, but it will give me something useful to do in the plane. You'll have the review as soon as get back on line, some 16 hours from now. Last call, gotta board now. [16 hours later...] Hi, Diego, Sorry, but I couldn't review the patch; the e-mail only had the URL. I'll be at conferences all day till the end of the week. I'll see if I can get on line and download the patch at the conference (the network connection at the hotel sucks rocks, I'm not even sure this e-mail will go out), but I probably won't be able to review it before the return flight. Gotta get some sleep now. I'm as exhausted as the IPv4 address space. :-) If it's not in my personal, local e-mail archives, it doesn't exist. IMNSHO, the cloud is smoke, and mirrors only help so much ;-) -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Tue, Feb 1, 2011 at 23:32, Gerald Pfeifer wrote: > On Tue, 1 Feb 2011, Dongsheng Song wrote: >>> The DATESTAMP change could also be in a post-commit hook (doing >>> nothing if the date didn't change, of course). No idea whether >>> this is technically possible of course. >> Yes, the post-commit hook can do this task. >> If we really want to do that, I can update the current post-commit >> hook script [1]. > > I'd love to see that and will be happy to work on this with you, > apply a patch, etc. > > Let's give others the chance to chime in, and if there are no > objections within the next two days, let's proceed. Fair? > > Gerald OK, let's waiting for comments now. Dongsheng
