6 Commits

Author SHA1 Message Date
Rafael Espindola
922f2aa9b2 Bring r325915 back.
The tests that failed on a windows host have been fixed.

Original message:

Start setting dso_local for COFF.

With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325940
2018-02-23 19:30:48 +00:00
Rafael Espindola
43ce3a3a4d Revert "Start setting dso_local for COFF."
This reverts commit r325915.

It will take some time to fix the failures on a windows host.

llvm-svn: 325929
2018-02-23 18:09:29 +00:00
Rafael Espindola
004d240b6a Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325915
2018-02-23 15:32:32 +00:00
Reid Kleckner
a283e48f69 Revert "Fix for PR32990"
This reverts commit r321239. It broke the Chromium DLL build:

[8834/50217] LINK(DLL) icui18n.dll icui18n.dll.lib icui18n.dll.pdb
FAILED: icui18n.dll icui18n.dll.lib icui18n.dll.pdb
zrule.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) public: void __cdecl icu_60::UnicodeString::`vbase destructor'(void)"
(__imp_??_DUnicodeString@icu_60@@QEAAXXZ)

llvm-svn: 321298
2017-12-21 19:44:23 +00:00
Erich Keane
abf9d6648c Fix for PR32990
This fixes the bug in https://bugs.llvm.org/show_bug.cgi?id=32990.

Patch By: zahiraam
Differential Revision: https://reviews.llvm.org/D39063

llvm-svn: 321239
2017-12-21 02:07:46 +00:00
Reid Kleckner
3da37e05f7 [MS] Don't bail on replacing dllimport vbase dtors with base dtors
Fix PR32990 by effectively reverting r283063 and solving it a different
way.

We want to limit the hack to not replace equivalent available_externally
dtors specifically to libc++, which uses always_inline. It seems certain
versions of libc++ do not provide all the symbols that an explicit
template instantiation is expected to provide.

If we get to the code that forms a real alias, only *then* check if this
is available_externally, and do that by asking a better question, which
is "is this a declaration for the linker?", because *that's* what means
we can't form an alias to it.

As a follow-on simplification, remove the InEveryTU parameter. Its last
use guarded this code for forming aliases, but we should never form
aliases to declarations, regardless of what we know about every TU.

llvm-svn: 315656
2017-10-13 00:53:02 +00:00