[Bug libstdc++/53429] New: complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11

[Bug libstdc++/53429] New: complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11

[jyasskin at gcc dot gnu.org]

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

             Bug #: 53429
           Summary: complex::{imag,real} should be marked alwaysinline to
                    guarantee libstdc++ binary compatibility between C++98
                    and C++11
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jyasskin@gcc.gnu.org


The non-const overloads of std::complex::real and std::complex::imag go from
returning _Tp& to _Tp in C++98 vs C++11:
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/std/complex?view=markup.
 libstdc++ includes explicit instantiations of operator<< and operator>> with
complex arguments:
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/src/c%2B%2B98/complex_io.cc?view=markup.
These operator<< and operator>> overloads call complex::real() and
complex::imag(). If those calls are inlined (which is likely), so that no weak
definition of real() and imag() is exposed to users of the library, then I
believe all is well. However, if the compiler decides not to inline them, then
people linking libstdc++ from the other version of the language may wind up
with two conflicting weak definitions of the symbols.

I think marking them as alwaysinline would guarantee compatibility.

[Bug libstdc++/53429] complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11

[jyasskin at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey Yasskin <jyasskin at gcc dot gnu.org> 2012-05-21 04:03:26 UTC ---
So far, this is purely a theoretical incompatibility. I haven't actually seen a
compiled libstdc++.so that exposes a version-specific complex::{imag,real}.

[Bug libstdc++/53429] complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-05-21 09:23:07 UTC ---
Note that C++98 and C++11 are not compatible anyway, for example due to the
changed way which classes are considered POD.

[Bug libstdc++/53429] complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11

[jyasskin at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey Yasskin <jyasskin at gcc dot gnu.org> 2012-05-21 15:30:45 UTC ---
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. If libstdc++.so exposed the c++98 version of complex::real(), then all
C++11 programs that used complex would be potentially broken.

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.

[Bug libstdc++/53429] complex::{imag,real} should be marked alwaysinline to guarantee libstdc++ binary compatibility between C++98 and C++11

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-05-21 15:59:44 UTC ---
Before fiddling with always inline, I would rather add 3 overloads of
operator<< for float, double and long double, using __rep instead of real and
imag. But I don't have a strong opinion about the PR (I have it about not using
the attribute ;) if somebody wants to do something, please double check with
Gaby.

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

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin <jyasskin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
   Last reconfirmed|                            |2012-05-22
                 CC|                            |gdr at gcc dot gnu.org
         Resolution|INVALID                     |
            Summary|complex::{imag,real} should |libstdc++ should guarantee
                   |be marked alwaysinline to   |not to expose
                   |guarantee libstdc++ binary  |complex::{imag,real} so it
                   |compatibility between C++98 |supports both C++98 and
                   |and C++11                   |C++11
     Ever Confirmed|0                           |1

--- Comment #5 from Jeffrey Yasskin <jyasskin at gcc dot gnu.org> 2012-05-22 12:58:14 UTC ---
Specializing operator<< sounds fine too. Adding Gaby for his opinion, and
reopening since I'm not sure Richard understood the request.