http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52765
Bug #: 52765
Summary: -std=c++0x requires multilib for non-optimized
libstdc++
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: christophe.l...@st.com
Hello,
While experimenting with -std=c++0x and libstdc++ built at -O0 [1], I noticed
that this sample code does not produce the expected result:
==================8<>===============
#include <iostream>
#include <complex>
int main()
{
const std::complex<float> cf (23., 101.);
std::cout << cf.real() << '\n';
std::cout << cf << '\n';
return 0;
}
==================8<>===============
That is, with -std=c++0x it prints:
23
(0,101)
and without -std=c++0x it prints:
23
(23,101)
This is because the call to cf.real() makes the compiler generate a 'c++0x'
variant of std::complex<float>::real() const, which is also called implicitly
by the library when printing the complex. But the library expects the non
'c++0x' version.
Admittedly, libstdc++ seems to be expected to compiled at -O2 and thus
std::complex<float>::real() is normally inlined, but I am wondering whether
there might be other functions in libstdc++ which would not be inlined at -O2
in the library itself, and thus subject to the same problem.
One way of having compliant libraries for me is to use multilib, but
understanding the root cause of such errors might not be easy for the average
user.
I am not sure this is really a bug (is building libstdc++ at -O0 supported?),
but at least I think it might be worth checking that other functions whose
prototype changes with -std=c++0x are always inlined in the library itself.
[1] I built libstdc++ at -O0 inadvertently, by overriding CFLAGS (not including
-O2) before building GCC.
