Re: using PCH branch to make precompiled std include

[Benjamin Kosnik <bkoz at redhat dot com>]

>On my P4 it's:
>0.180u 0.010s 0:00.19 100.0%
>vs
>1.030u 0.010s 0:01.04 100.0%
>
>Pretty good!

Definitely worth trying out, I think! This is really good news.

>/tmp/ccSZfk3p.o: In function `main':
>/tmp/ccSZfk3p.o(.text+0x18): undefined reference to 
>`std::allocator<char>::allocator[in-charge]()'

stl-inst.cc

>/tmp/ccSZfk3p.o(.text+0x32): undefined reference to 
>`std::basic_string<char, std::char_traits<char>, std::allocator<char> 
> >::basic_string[in-charge](char const*, std::allocator<char> const&)'

string-inst.cc

>/tmp/ccSZfk3p.o(.text+0x71): undefined reference to 
>`std::basic_ostream<char, std::char_traits<char> >& std::operator<< 
><char, std::char_traits<char>, std::allocator<char> 

ostream-inst.cc

>collect2: ld returned 1 exit status

These are all things that are explicitly instantiated in source files,
and then "extern template" ified in the include files. Does the
libstdc++ binary in the PCH build directory have these bits? If not,
that's a bug. If you build a PCH, and then use it all the time in a
re-jiggered full testsuite run, do things work, or fall down? Looks like
things might not get very far if this simple program doesn't make it.

Sounds like there might be some linkage issues. I'll get back to this
later in the week, I think, after the config/build bits and
__cxa_demangle bits get finished.

Is there a list of known issues and bugs in the current PCH implementation?

-benjamin