Re: [Proposed binutils PATCH] Re: Diagnosing an intricate C++ problem

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <Pine.BSF.4.21.0009021957530.89194-100000@taygeta.dbai.tuwien.ac.at>,
Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> That toolchain nicely diagnoses my original problem,

Great!

> but this one seems to be more serious than I originally thought, the
> problem being standard libraries like libstdc++.

No, not really.  See below.

>> I can also imagine that the linking process could slow down under
>> heavily-templated code.  However, for all the small, multi-file STL
>> examples that I had lying around, (1) I found no measurable slowdown
>> and (2) no false warnings unless I compiled some files with
>> -fomit-frame-pointer and some without (interestingly, even adding -O
>> didn't change the linkonce sections as I expected it might).

> Yes (and sorry that it took that long): My production stuff linked
> successfully, but produced tons of warnings.

> #include <string>
> #include <vector>

> main() {
>     vector<string> w;

>     w.push_back("Hello");
>     }

> for which a simple `g++ x.cc` generates the following warnings:

[...warnings removed...]

I attempted your example, but saw no such warnings.  Here is why (and
why I didn't generally see this issue before myself):

[Unlike you, I configure with --enable-shared.  Perhaps by default or
 my own setup, libstdc++ is built with -O2 in my environment.]

$ /usr/local/beta-gcc/bin/g++ x.cc
$ /usr/local/beta-gcc/bin/g++ -static x.cc
[All the errors you see.]
$ /usr/local/beta-gcc/bin/g++ -static -O2 x.cc

If possible, try building all your production code with the exact same
flags as was used to build the C++ library.  The trap you fell into
signals to me that this patch must be revised to make it a
well-documented option instead of on by default.  I will rework the
patch precisely one week and three days from now.