and only consider using __cxa_atexit in the Itanium logic. The
default logic is to use atexit().
Emit "guarded" initializers in Microsoft mode unconditionally.
This is definitely not correct, but it's closer to correct than
just not emitting the initializer.
Based on a patch by Timur Iskhodzhanov!
llvm-svn: 155894
I broke this in r155838 by not actually instantiating non-dependent default arg
expressions. The motivation for that change was to avoid producing duplicate
conversion warnings for such default args (we produce them once when we parse
the template - there's no need to produce them at each instantiation) but
without actually instantiating the default arg, things break in weird ways.
Technically, I think we could still get the right diagnostic experience without
the bugs if we instantiated the non-dependent args (for non-dependent params
only) immediately, rather than lazily. But I'm not sure if such a refactoring/
change would be desirable so here's the conservative fix for now.
llvm-svn: 155893
what I'm going to treat as basically universal properties of
array-cookie code. Implement MS array cookies on top of that.
Based on a patch by Timur Iskhodzhanov!
llvm-svn: 155886
the tempale arguments in deciding the visibility.
This agrees with gcc 4.7.
Found by trying to build chrome with component=shared_library with 155314
reverted.
llvm-svn: 155316
type llvm::ArrayType -- sometimes we emit them as packed structs. Don't assert
if such a global array has an element type with a non-trivial destructor.
llvm-svn: 155305
This fixes the included testcase and lets us simplify the code a bit. It
does require using mergeWithMin when merging class information to its
members. Expand the comments to explain why that works.
llvm-svn: 155103
an explicit default one. This means that with -fvisibility hidden we
now produce a hidden symbol for
template <typename T>
class DEFAULT foo {
void bar() {}
};
class zed {};
template class foo<zed>;
This matches the behaviour of gcc 4.7.
llvm-svn: 155102
specifications on member function templates of class templates and other such
nested beasties. Store the function template from which we are to instantiate
an exception specification rather than trying to deduce it. Plus some
additional test cases.
llvm-svn: 155076
We have a new flavor of exception specification, EST_Uninstantiated. A function
type with this exception specification carries a pointer to a FunctionDecl, and
the exception specification for that FunctionDecl is instantiated (if needed)
and used in the place of the function type's exception specification.
When a function template declaration with a non-trivial exception specification
is instantiated, the specialization's exception specification is set to this
new 'uninstantiated' kind rather than being instantiated immediately.
Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs
on-demand. Also, any odr-use of a function triggers the instantiation of its
exception specification (the exception specification could be needed by IRGen).
In passing, fix two places where a DeclRefExpr was created but the corresponding
function was not actually marked odr-used. We used to get away with this, but
don't any more.
Also fix a bug where instantiating an exception specification which refers to
function parameters resulted in a crash. We still have the same bug in default
arguments, which I'll be looking into next.
This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to
parse (and, in very limited testing, support) all of libstdc++4.7's standard
headers.
llvm-svn: 154886
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type.
The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.
Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.
Fixes PR10036 and PR12450.
llvm-svn: 154799
initialize an array of unsigned char. Outside C++11 mode, this bug was benign,
and just resulted in us emitting a constant which was double the required
length, padded with 0s. In C++11, it resulted in us generating an array whose
first element was something like i8 ptrtoint ([n x i8]* @str to i8).
llvm-svn: 154756
jump into these scopes, and the cleanup-entering code sometimes wants
to do some operations first (e.g. a GEP), which can leave us with
unparented IR.
llvm-svn: 154684
in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
means actually using initialization semantics for this initialization,
rather than just creating a store.
On a related note, make sure we actually put in non-atomic-to-atomic
conversions when performing an implicit conversion sequence. IR
generation is far too kind here, but we still want the ASTs to make
sense.
llvm-svn: 154612
global destructor entry. For some reason this isn't enabled for
apple-kexts; it'd be good to have documentation for that.
Based on a patch by Nakamura Takumi!
llvm-svn: 154191
number + context) to the point where we initially start defining the
lambda, so that the linkage won't change when that information is made
available. Fixes the assertion in <rdar://problem/11182962>.
Plus, actually mangle the context of lambdas properly.
llvm-svn: 154029
This was caused by the code deciding the number of fields in the byref structure using a different test to the part of the code creating the GEPs into said structure.
llvm-svn: 154013
property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration. Use the current scope
location as a separate parameter so that we can match it up
better in the line table with the beginning of the scope.
Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart
and for the new metadata parameter and add a new testcase to
make sure we've got the right line numbers for synthesized
properties.
Part of rdar://11026482
llvm-svn: 153917
the function body, but do so in a way that doesn't make any assumptions
about the static local actually having a proper, unique mangling,
since apparently we don't do that correctly at all.
llvm-svn: 153776
These patches cause us to miscompile and/or reject code with static
function-local variables in an extern-C context. Previously, we were
papering over this as long as the variables are within the same
translation unit, and had not seen any failures in the wild. We still
need a proper fix, which involves mangling static locals inside of an
extern-C block (as GCC already does), but this patch causes pretty
widespread regressions. Firefox, and many other applications no longer
build.
Lots of test cases have been posted to the list in response to this
commit, so there should be no problem reproducing the issues.
llvm-svn: 153768
the case that the variable already exists. Partly this is just
protection against people making crazy declarations with custom
asm labels or extern "C" names that intentionally collide with
the manglings of such variables, but the main reason is that we
can actually emit a static local variable twice with the
requirement that it match up. There may be other cases with
(e.g.) the various nested functions, but the main exemplar is
with constructor variants, where we can be forced into
double-emitting the function body under certain circumstances
like (currently) the presence of virtual bases.
llvm-svn: 153723
John McCall