This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/53429] libstdc++ should guarantee not to expose complex::{imag,real} so it supports both C++98 and C++11


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53429

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.8.0

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jeffrey Yasskin from comment #3)
> Richard, I'm not asking that it be possible to link together code compiled
> in C++98 and C++11 mode. I'm asking that gcc be able to build in C++11 mode
> at all.

Even if we build GCC in C++11 (or C++14) mode, some pieces of libstdc++ get
built with -std=gnu++98 explicitly. That's why they're in the
libstdc++-v3/src/c++98 directory.

> If libstdc++.so exposed the c++98 version of complex::real(), then
> all C++11 programs that used complex would be potentially broken.

I don't think this is true now, because those functions are abi-tagged for
C++11 and later, so C++11 programs would not use the symbols exported from the
library (assuming such symbols existed, and if they did the check-abi testsuite
target would fail for our primary targets, so we'd notice and it wouldn't just
happen silently due to bad luck and different inlining decisions).

So I think this was fixed for 4.8.0 by r193445, but please reopen if I'm
missing something and a potential problem still exists.

> Another way to fix this would, of course, be to either expose a
> configuration option to build libstdc++.so in C++11 mode or to install two
> different .so files in parallel, but doing that seems unnecessarily hostile
> to users when it would be pretty easy to guarantee that the one .so works
> for both versions of the language.

We definitely don't want two libs.

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