[Bug c++/48818] New: Wrong copy constructor used when using std::pair in .so and app.

[Bug c++/48818] New: Wrong copy constructor used when using std::pair in .so and app.

[melaniec at enfocus dot com]

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

           Summary: Wrong copy constructor used when using std::pair in
                    .so and app.
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: melaniec@enfocus.com


Created attachment 24142
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24142
Test library and app as illustration of the bug.

Attached is a test application and a shared library it is linked with. If the
wrong copy constructor is used, it will write an error. 

Both the application and the library have a local but different class
"TestObject". Both application and library use a std::pair<TestObject, void*>. 
When the copy constructor of the library's TestObject is called by the
std::pair in the library, the copy constructor from the application's
TestObject is used. This does not happen if the application doesn't have a
std::pair<TestObject, void*>. 

Tested ok with 4.1.3.
Failed with 4.2.1, 4.3.4, 4.4.1, 4.5.1 (I couldn't test it readily with a more
recent version.)

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.04.29 10:24:20
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-29 10:24:20 UTC ---
Confirmed.  Even with -fvisibility=hidden we have

    28: 0000000000000000    17 FUNC    WEAK   HIDDEN    13 _ZN10TestObjectC2Ev
    29: 0000000000000000    17 FUNC    WEAK   HIDDEN    13 _ZN10TestObjectC1Ev
    33: 0000000000000000    46 FUNC    WEAK   DEFAULT   15
_ZNSt4pairI10TestObje
ctPv
    37: 0000000000000000    46 FUNC    WEAK   DEFAULT   15
_ZNSt4pairI10TestObje
ctPv

You can work around this by linking the shared library with -Bsymbolic to
force local symbol resolution.

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.

[melaniec at enfocus dot com]

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

--- Comment #2 from Melanie Cappelaere <melaniec at enfocus dot com> 2011-05-04 14:19:01 UTC ---
Created attachment 24181
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24181
Example with custom allocator

Thank you for the workaround.

Little side note: this bug also applies to stl containers using a custom
allocator that happens to have the same name and occurs in both the application
and the library. Allocation is done using the library's allocator, but
deallocation is done using the application's. (The workaround also works in
this case.)

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.

[bangerth at gmail dot com]

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

Wolfgang Bangerth <bangerth at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at gmail dot com

--- Comment #3 from Wolfgang Bangerth <bangerth at gmail dot com> 2011-05-26 05:44:18 UTC ---
Are you saying that you have classes that have the same name but are different?
This violates the One Definition Rule, no?

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.

[melaniec at enfocus dot com]

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

--- Comment #4 from Melanie Cappelaere <melaniec at enfocus dot com> 2011-06-06 16:27:22 UTC ---
I don't think it does, but it also doesn't matter for this bug report; symbols
are not hidden while they should be.

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app.

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |almeidaraf at gmail dot com

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-02 09:30:32 UTC ---
*** Bug 50270 has been marked as a duplicate of this bug. ***

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app. -fvisibility=hidden does not work

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-20 01:19:49 UTC ---
I would be curious to know if you are seeing something else when you configure
your build with --disable-visibility.

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app. -fvisibility=hidden does not work

[vincenzo.innocente at cern dot ch]

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

--- Comment #7 from vincenzo Innocente <vincenzo.innocente at cern dot ch> 2011-10-20 07:27:30 UTC ---
no side effects for the time being.
I've tried only small applications though.
I would suggest to rename --disable-visibility
--disable-std-visibility or similar as, applied to top level configure, it is
not very informative about
its semantics

[Bug c++/48818] Wrong copy constructor used when using std::pair in .so and app. -fvisibility=hidden does not work

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-10-20 08:23:01 UTC ---
Vincenzo, I agree about the name, yesterday had the same thought. Then we have
the usual annoyances with configure options and switches, we normally don't
want to just rename in order to not break build systems, scripts, etc. I'll see
what we can do, ideally add an alias and deprecate the old one.