This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: patch to check ld
- To: bkoz at redhat dot com, Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr
- Subject: Re: patch to check ld
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Wed, 26 Jul 2000 15:28:27 -0400
- Cc: libstdc++ at sources dot redhat dot com
Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>:
> Benjamin Kosnik <bkoz@redhat.com> writes:
>
> | FYI this is the snippet of email that prompted the decision to add the flags:
> |
> | > GNU ld does try to mitigate the problem by adapting the hash table
> | > size (and thus hash key modulus) to minimize hash collisions, chain
> | > length, and number of pages in the hash table. It's pretty slick.
> |
> | But you have to add -O1 to the linker line which most people don't do
>
> Shouldn't that go into the specs? That seems to me to be the right
> place to do that sort of black magic instead of requiring users to
> manually play with that tricky flag, IMHO.
I didn't even know that gld /had/ an optimization flag until today. I
looked through the docs, and found this:
-O level
If level is a numeric values greater than zero ld optimizes
the output. This might take significantly longer and therefore
probably should only be enabled for the final binary.
I could see the linker's -On only being turned on at the compiler's
-O(n+delta), but (n+delta) would probably still be used for all the object
files, not just the final step.
Maybe gcc needs an -Ofinal to do things that only make good sense when
creating a binary (or a library).
Phil