| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Static locals requiring initialization are not thread safe on Windows.
Unfortunately, it's possible to create static locals that are actually
externally visible with inline functions and templates. As a result, we
have to implement an initialization guard scheme that is compatible with
TUs built by MSVC, which makes thread safety prohibitively difficult.
MSVC's scheme is that every function that requires a guard gets an i32
bitfield. Each static local is assigned a bit that indicates if it has
been initialized, up to 32 bits, at which point a new bitfield is
created. MSVC rejects inline functions with more than 32 static locals,
and the externally visible mangling (?_B) only allows for one guard
variable per function.
On Eli's recommendation, I used MangleNumberingContext to track which
bit each static corresponds to.
Implements PR16888.
Reviewers: rjmccall, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1416
llvm-svn: 190427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This also relaxes the requirement on Windows that the member pointer
class type be a complete type (http://llvm.org/PR12070). We still ask
for a complete type to instantiate any templates (MSVC does this), but
if that fails we continue as normal, relying on any inheritance
attributes on the declaration.
Reviewers: rjmccall
CC: triton, timurrrr, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D568
llvm-svn: 178283
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
| |
|
|
|
|
| |
PR12785
llvm-svn: 160121
|
| |
|
|
|
|
|
|
| |
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
|
| |
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
| |
|
|
| |
llvm-svn: 124646
|
| |
|
|
|
|
| |
as well.
llvm-svn: 120137
|
| |
|
|
|
|
|
| |
This isn't used yet, because someone more experienced than I needs to look
at the type system about gutting getCanonicalCallConv().
llvm-svn: 117638
|
| |
|
|
|
|
|
| |
it deserves its own enumerator. Obviously the implementations should
closely follow the Itanium ABI except in cases of divergence.
llvm-svn: 111749
|
|
|
AST library.
This also adds infrastructure for supporting multiple C++ ABIs in the AST.
llvm-svn: 111117
|