Commit Graph

13 Commits

Author SHA1 Message Date
Rafael Espindola 9cd752533e Make this test a bit stricter.
The first function is named __cxx_global_var_init, which is a substring of
the following functions @__cxx_global_var_init(1,2,3,etc).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225191 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-05 18:48:18 +00:00
Reid Kleckner 51847c2025 Don't use a global_ctors comdat for globals that aren't externally visible
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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219806 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-15 16:38:00 +00:00
Reid Kleckner f867c44a02 Revert "Don't use comdats for initializers on platforms that don't support it"
On further investigation, COMDATs should work with .ctors, and the issue
I was hitting probably reproduces with .init_array.

This reverts commit r218287.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218313 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-23 16:20:01 +00:00
Reid Kleckner 1a209b667f Don't use comdats for initializers on platforms that don't support it
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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218287 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-23 00:00:14 +00:00
Rafael Espindola 10d9becab7 Don't use the third field of llvm.global_ctors for MachO.
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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218097 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-19 01:54:22 +00:00
Reid Kleckner 8756959802 Use comdats to avoid double initialization of weak data
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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209555 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-23 21:13:45 +00:00
Nico Weber afafe70f43 Include translation unit filename in global ctor symbol names.
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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208128 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-06 20:32:45 +00:00
Richard Smith ecbce69e35 Implement restriction that a partial specialization must actually specialize
something, for variable templates.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191278 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-24 04:49:23 +00:00
David Blaikie 0d520f7d2e Do not emit duplicate global initializers for template static data members inside namespaces
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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189996 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-04 21:07:37 +00:00
Reid Kleckner c47063e1e6 Order initializers of static data members of explicit specializations
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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189898 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-04 00:54:24 +00:00
Reid Kleckner b969e84ec3 Add a separate llvm.global_ctors entry for linkonce_odr data initializers
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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189051 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-22 20:07:45 +00:00
Daniel Dunbar a5728872c7 Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- 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).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-15 20:14:24 +00:00
Anders Carlsson 1b3171dd6c Don't emit explicit specializations of static member variable declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90624 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-04 23:50:01 +00:00