In particular, if you have two identical templates in different TUs in
anonymous namespaces, we would use the same global_ctors comdat key for
both. As a result, only one would be run.
llvm-svn: 219806
On further investigation, COMDATs should work with .ctors, and the issue
I was hitting probably reproduces with .init_array.
This reverts commit r218287.
llvm-svn: 218313
In particular, pre-.init_array ELF uses the .ctors section mechanism.
MinGW COFF also uses .ctors, now that I think about it. Therefore,
restrict this optimization to the two platforms that are currently known
to work: ELF with .init_array and COFF with .CRT$XCU.
llvm-svn: 218287
The field is defined as:
If the third field is present, non-null, and points to a global variable or function, the initializer function will only run if the associated data from the current module is not discarded.
And without COMDATs we can't implement that.
llvm-svn: 218097
Initializers of global data that can appear multiple TUs (static data
members of class templates or __declspec(selectany) data) are now in a
comdat group keyed on the global variable being initialized. On
non-Windows platforms, this is a code size and startup time
optimization. On Windows, this is necessary for ABI compatibility with
MSVC.
Fixes PR16959.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3811
llvm-svn: 209555
This makes it easier to see where a global ctor comes from, and it also makes
ASan's init order analyzer output easier to understand. gcc does this too,
but only in -fPIC mode for some reason. Don't do this for constructors with
explicit init priority.
Also prepend "sub_" before the 'I', that way regular constructors stay
lexicographically after symbols with init priority (because
ord('s') > ord('I')). gold seems to ignore the name of constructor symbols,
and ld only looks at the symbol if it includes an init priority, which this
patch doesn't change.
Before: __GLOBAL_I_a
Now: __GLOBAL_sub_I_myfile.cc
llvm-svn: 208128
A quirk of AST representation leads to class template static data member
definitions being visited twice during Clang IRGen resulting in
duplicate (benign) initializers.
Discovered while investigating a possibly-related debug info bug tickled
by the duplicate emission of these members & their associated debug
info.
With thanks to Richard Smith for help investigating, understanding, and
helping with the fix.
llvm-svn: 189996
I tried to implement this properly in r189051, but I didn't have enough
test coverage. Richard kindly provided more test cases than I could
possibly imagine and now we should have the correct condition.
llvm-svn: 189898
Summary:
These typically come from static data members of class template
specializations. This accomplishes two things:
1. May expose GlobalOpt optimizations for Itanium C++ ABI code.
2. Works toward fixing double initialization in the Microsoft C++ ABI.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1475
llvm-svn: 189051
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
Reid Kleckner