This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: patch to check ld



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]