[cfe-dev] Problems with modern versions of libstdc++

[Douglas Gregor]

On Feb 17, 2010, at 5:40 AM, Christopher Jefferson wrote:

> I have been using clang++ to compile some code, and have been finding problems arising from which version of g++ is installed as the system compiler. I was wondering what the policy is on fixing bugs and keeping this working:
> 
> 
> Using g++ 4.2 as the system compiler, the following works fine:
> 
> #include <tr1/array>
> #include <ostream>
> 
> int main(void) {}
> 
> 
> Once I update to g++ 4.4, #include <tr1/array> breaks, as g++ switches to using variadic templates even in TR1.

There isn't anything we can do about this until we implement the C++0x features that g++ uses in its TR1 implementation. C++0x features are, generally, of a much lower priority than making C++98/03 work well, so this won't happen soon.

For reference, this affects the TR1 components in GCC 4.3 and newer, and many of the headers when compiled in C++0x mode.

> More worryingly, once I upgrade to a current svn version of g++ 4.5, <ios> (and therefore most files involving streams, including ostream/istream/fstream) fails to compile due to the following code in locale_facets.h
> 
> template<typename _Tv>
>   void
>   __convert_to_v(const char* __in, _Tv& __out, ios_base::iostate& __err,
>    const __c_locale& __cloc);
> 
> 
> template<>
>   void
>   __convert_to_v(const char*, float&, ios_base::iostate&,
>    const __c_locale&) throw();
> 
> Which fails to compile with the error:
> 
> /gccsvn/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../../include/c++/4.5.0/bits/locale_facets.h:71:5: error: 
>     exception specification in declaration does not match previous declaration
>   __convert_to_v(const char*, float&, ios_base::iostate&,
>   ^
> /gccsvn/lib/gcc/x86_64-apple-darwin10.2.0/4.5.0/../../../../include/c++/4.5.0/bits/locale_facets.h:65:5: note: 
>     previous declaration is here
>   __convert_to_v(const char* __in, _Tv& __out, ios_base::iostate& __err,
>   ^
> 
> 
> Should such bugs be reported up-stream?

Yes, this code is ill-formed and should reported to them.

> Would clang add support for such g++-specific code, if it was not fixed upstream?


If they don't fix it by the time GCC 4.5 is released, we'll probably be forced to put in some kind of compatibility hack, e.g., downgrading this error to a warning. Compatibility with libstdc++ is extremely important: look for __is_pod in the Clang parser to see what horrible things we've already done toward this goal :)

	- Doug