Multiple-defined __destructor_1, __destructor_8 when building with recent clang-cl

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple-defined __destructor_1, __destructor_8 when building with recent clang-cl

Tom Stellard via cfe-dev
After a recent pull of LLVM/Clang trunk, my clang-cl build of
LibreOffice on Windows started to fail to link some DLL because of
__destructor_1 and __destructor_8 symbols defined in multiple objects.

I haven't been able yet to strip that down, and looking at the objects'
assembler output it isn't clear to me what those symbols are emitted for.

Do those symbols maybe ring a bell for anybody?  Is that some recent
addition?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Multiple-defined __destructor_1, __destructor_8 when building with recent clang-cl

Tom Stellard via cfe-dev
Looks like Akira added a bunch of stuff for this in r326307. It is supposed to relate to ARC and __strong, __weak, etc. It's pretty complex. :(

That code does not appear to work for non-MachO. It creates LLVM IR functions directly without going through the usual CGM codepaths, so it doesn't add a comdat.

On Wed, Apr 4, 2018 at 1:32 AM Stephan Bergmann via cfe-dev <[hidden email]> wrote:
After a recent pull of LLVM/Clang trunk, my clang-cl build of
LibreOffice on Windows started to fail to link some DLL because of
__destructor_1 and __destructor_8 symbols defined in multiple objects.

I haven't been able yet to strip that down, and looking at the objects'
assembler output it isn't clear to me what those symbols are emitted for.

Do those symbols maybe ring a bell for anybody?  Is that some recent
addition?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Multiple-defined __destructor_1, __destructor_8 when building with recent clang-cl

Tom Stellard via cfe-dev
On Apr 4, 2018, at 3:07 PM, Reid Kleckner via cfe-dev <[hidden email]> wrote:

Looks like Akira added a bunch of stuff for this in r326307. It is supposed to relate to ARC and __strong, __weak, etc. It's pretty complex. :(

That code does not appear to work for non-MachO. It creates LLVM IR functions directly without going through the usual CGM codepaths, so it doesn't add a comdat.

I would not have expected this patch to affect the compilation of ordinary C++ code.

John.


On Wed, Apr 4, 2018 at 1:32 AM Stephan Bergmann via cfe-dev <[hidden email]> wrote:
After a recent pull of LLVM/Clang trunk, my clang-cl build of
LibreOffice on Windows started to fail to link some DLL because of
__destructor_1 and __destructor_8 symbols defined in multiple objects.

I haven't been able yet to strip that down, and looking at the objects'
assembler output it isn't clear to me what those symbols are emitted for.

Do those symbols maybe ring a bell for anybody?  Is that some recent
addition?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Multiple-defined __destructor_1, __destructor_8 when building with recent clang-cl

Tom Stellard via cfe-dev
r326307 and r327870 made changes that allow declaring ObjC __strong and __weak fields in C structs, so they shouldn't have any effect if you are compiling your code in C++ mode. Is it possible to come up with a small C++ test case that causes clang to emit the destructor functions you are seeing?

On Wed, Apr 4, 2018 at 12:16 PM, John McCall <[hidden email]> wrote:
On Apr 4, 2018, at 3:07 PM, Reid Kleckner via cfe-dev <[hidden email]> wrote:

Looks like Akira added a bunch of stuff for this in r326307. It is supposed to relate to ARC and __strong, __weak, etc. It's pretty complex. :(

That code does not appear to work for non-MachO. It creates LLVM IR functions directly without going through the usual CGM codepaths, so it doesn't add a comdat.

I would not have expected this patch to affect the compilation of ordinary C++ code.

John.


On Wed, Apr 4, 2018 at 1:32 AM Stephan Bergmann via cfe-dev <[hidden email]> wrote:
After a recent pull of LLVM/Clang trunk, my clang-cl build of
LibreOffice on Windows started to fail to link some DLL because of
__destructor_1 and __destructor_8 symbols defined in multiple objects.

I haven't been able yet to strip that down, and looking at the objects'
assembler output it isn't clear to me what those symbols are emitted for.

Do those symbols maybe ring a bell for anybody?  Is that some recent
addition?
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Why is the deque's Allocator default initializer commented?

Tom Stellard via cfe-dev
libc++
 
file: include/deque
 
1185
1186 template <class _Tp, class _Allocator /*= allocator<_Tp>*/>
1187 class _LIBCPP_TEMPLATE_VIS deque
1188     : private __deque_base<_Tp, _Allocator>
1189 {
 
Why is the deque's Allocator default initializer commented?
 
I can write this code below:
 
#include <deque>
int main()
{
    std::deque<int> u;
    
    return 0;
}
 
So, shouldn't the default initializer be present there?
 
PS: May I do questions like this in this mailing list?

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Why is the deque's Allocator default initializer commented?

Tom Stellard via cfe-dev
This link
http://www.cplusplus.com/reference/deque/deque/
has:
template < class T, class Alloc = allocator<T> > class deque;
 
and this link
http://en.cppreference.com/w/cpp/container/deque
has
template<

    class T,
    class Allocator = std::allocator<T>

> class deque;
 
I dont understand two things:
 
1- Why is it working without parameter initialization?
2- Why the initialization was commented?
 
Sent: Wednesday, April 04, 2018 at 11:21 PM
From: "Christiano SA via cfe-dev" <[hidden email]>
To: [hidden email]
Subject: [cfe-dev] Why is the deque's Allocator default initializer commented?
libc++
 
file: include/deque
 
1185
1186 template <class _Tp, class _Allocator /*= allocator<_Tp>*/>
1187 class _LIBCPP_TEMPLATE_VIS deque
1188     : private __deque_base<_Tp, _Allocator>
1189 {
 
Why is the deque's Allocator default initializer commented?
 
I can write this code below:
 
#include <deque>
int main()
{
    std::deque<int> u;
    
    return 0;
}
 
So, shouldn't the default initializer be present there?
 
PS: May I do questions like this in this mailing list?
_______________________________________________ cfe-dev mailing list [hidden email] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Why is the deque's Allocator default initializer commented?

Tom Stellard via cfe-dev
I understood:
 
line 172:
template <class _Tp, class _Allocator = allocator<_Tp> > class _LIBCPP_TEMPLATE_VIS deque;
The declaration has the " = allocator<_Tp>".
 
Thanks, Topper.
 
Sent: Wednesday, April 04, 2018 at 11:30 PM
From: "Christiano SA via cfe-dev" <[hidden email]>
To: [hidden email]
Subject: Re: [cfe-dev] Why is the deque's Allocator default initializer commented?
This link
has:
template < class T, class Alloc = allocator<T> > class deque;
 
and this link
has
template<

    class T,
    class Allocator = std::allocator<T>

> class deque;
 
I dont understand two things:
 
1- Why is it working without parameter initialization?
2- Why the initialization was commented?
 
Sent: Wednesday, April 04, 2018 at 11:21 PM
From: "Christiano SA via cfe-dev" <[hidden email]>
To: [hidden email]
Subject: [cfe-dev] Why is the deque's Allocator default initializer commented?
libc++
 
file: include/deque
 
1185
1186 template <class _Tp, class _Allocator /*= allocator<_Tp>*/>
1187 class _LIBCPP_TEMPLATE_VIS deque
1188     : private __deque_base<_Tp, _Allocator>
1189 {
 
Why is the deque's Allocator default initializer commented?
 
I can write this code below:
 
#include <deque>
int main()
{
    std::deque<int> u;
    
    return 0;
}
 
So, shouldn't the default initializer be present there?
 
PS: May I do questions like this in this mailing list?
_______________________________________________ cfe-dev mailing list [hidden email] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________ cfe-dev mailing list [hidden email] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Multiple-defined __destructor_1, __destructor_8 when building with recent clang-cl

Tom Stellard via cfe-dev
In reply to this post by Tom Stellard via cfe-dev
On 04/04/18 23:32, Akira Hatanaka wrote:
> r326307 and r327870 made changes that allow declaring ObjC __strong and
> __weak fields in C structs, so they shouldn't have any effect if you are
> compiling your code in C++ mode. Is it possible to come up with a small
> C++ test case that causes clang to emit the destructor functions you are
> seeing?

Filed <https://bugs.llvm.org/show_bug.cgi?id=37146> "clang-cl emits
special functions for non-trivial C-structs ('__destructor_8')
introduced for Objective-C" now, with reproducer.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev