| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
produce an invalid location even when given a valid location, if the
file system has changed underneath us. Recovery more gracefully.
llvm-svn: 118834
|
| |
|
|
|
|
| |
a test change, all for blocks. wip.
llvm-svn: 118745
|
| |
|
|
|
|
|
|
|
| |
NEON vector types need to be mangled in a special way to comply with ARM's ABI,
similar to some of the AltiVec-specific vector types. This patch is mostly
just renaming a bunch of "AltiVecSpecific" things, since they will no longer
be specific to AltiVec. Besides that, it just adds the new "NeonVector" enum.
llvm-svn: 118724
|
| |
|
|
|
|
|
|
| |
mangler. Now member functions and pointers thereof have their calling
convention mangled as __thiscall if they have the default CC (even though,
they technically still have the __cdecl CC).
llvm-svn: 118598
|
| |
|
|
| |
llvm-svn: 118498
|
| |
|
|
|
|
| |
Fix linux build.
llvm-svn: 118497
|
| |
|
|
|
|
| |
a first step towards fixing PR6995.
llvm-svn: 118491
|
| |
|
|
|
|
| |
Fixes rdar://8644873 & http://llvm.org/PR8567.
llvm-svn: 118468
|
| |
|
|
|
|
|
|
|
|
|
|
| |
there's no return adjustment from the overridden to the overrider doesn't
mean there isn't a return adjustment from the overrider to the final
overrider. This matters if we're emitting a virtual this-adjustment thunk
because the overrider virtually inherits from the class providing the
nearest overridden method. Do the appropriate return adjustment in this case.
Fixes PR7611.
llvm-svn: 118466
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
abstractions (e.g., TemplateArgumentListBuilder) that were designed to
support variadic templates. Only a few remnants of variadic templates
remain, in the parser (parsing template type parameter packs), AST
(template type parameter pack bits and TemplateArgument::Pack), and
Sema; these are expected to be used in a future implementation of
variadic templates.
But don't get too excited about that happening now.
llvm-svn: 118385
|
| |
|
|
| |
llvm-svn: 118366
|
| |
|
|
|
|
|
|
|
| |
data members by delaying the emission of the initializer until after
linkage and visibility have been set on the global. Also, don't
emit a guard unless the variable actually ends up with vague linkage,
and don't use thread-safe statics in any case.
llvm-svn: 118336
|
| |
|
|
| |
llvm-svn: 118238
|
| |
|
|
| |
llvm-svn: 118236
|
| |
|
|
| |
llvm-svn: 118172
|
| |
|
|
|
|
| |
visibility of their function.
llvm-svn: 118065
|
| |
|
|
|
|
| |
// rdar: //8620510 and PR7666
llvm-svn: 118019
|
| |
|
|
| |
llvm-svn: 117928
|
| |
|
|
|
|
| |
getBaseClassOffset which returns the offset in CharUnits. Do the same thing for getVBaseClassOffset.
llvm-svn: 117881
|
| |
|
|
|
|
|
|
|
|
| |
independently of whether they're definitions, then teach IR generation to
ignore non-explicit visibility when emitting declarations. Use this to
make sure that RTTI, vtables, and VTTs get the right visibility.
More of rdar://problem/8613093
llvm-svn: 117781
|
| |
|
|
|
|
|
|
|
| |
in asm's. PR 8501, 8602988.
I don't like including Type.h where it is; the idea was
to get references to X86_MMXTy out of the common code.
Maybe there's a better way?
llvm-svn: 117736
|
| |
|
|
| |
llvm-svn: 117734
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for namespace-scope variable declarations.
Apply visibility in IR gen to variables that are merely declared
and never defined. We were previously emitting these with default
visibility unless they were declared with private_extern.
Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.
llvm-svn: 117729
|
| |
|
|
|
|
| |
This is tested by funcargs.exp in gdb testsuite.
llvm-svn: 117659
|
| |
|
|
|
|
| |
declared", it breaks things.
llvm-svn: 117653
|
| |
|
|
|
|
| |
anyone has ever intentionally done this outside of a compiler test case.
llvm-svn: 117645
|
| |
|
|
|
|
|
|
|
|
|
|
| |
and never defined. We were previously emitting these with default
visibility unless they were declared with private_extern.
Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.
llvm-svn: 117644
|
| |
|
|
|
|
| |
most level.
llvm-svn: 117613
|
| |
|
|
|
|
|
|
| |
using the memory type; fixes an assert.
Fixes rdar://problem/8605032
llvm-svn: 117610
|
| |
|
|
| |
llvm-svn: 117576
|
| |
|
|
| |
llvm-svn: 117561
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the scope checker. With that done, turn an indirect goto into a
protected scope into a hard error; otherwise IR generation has to start
worrying about declarations not dominating their scopes, as exemplified
in PR8473.
If this really affects anyone, I can probably adjust this to only hard-error
on possible indirect gotos into VLA scopes rather than arbitrary scopes.
But we'll see how people cope with the aggressive change on the marginal
feature.
llvm-svn: 117539
|
| |
|
|
|
|
| |
Radar 8595129
llvm-svn: 117507
|
| |
|
|
|
|
|
| |
aggressive about the form we expect bools to be in. I don't really have
time to fix all the sources right now.
llvm-svn: 117486
|
| |
|
|
| |
llvm-svn: 117456
|
| |
|
|
|
|
|
|
| |
on if its linkage is weak. Currently this is the
case but may change in the future. (part of radar
8562966).
llvm-svn: 117452
|
| |
|
|
|
|
| |
been marked final.
llvm-svn: 117445
|
| |
|
|
|
|
| |
calls to it.
llvm-svn: 117444
|
| |
|
|
|
|
|
| |
of static data member of a class template.
Fixes //rdar :// 8562966 and pr8409.
llvm-svn: 117410
|
| |
|
|
|
|
|
| |
in IR gen, and use those to fix a correctness issue with bool atomic
intrinsics. rdar://problem/8461234
llvm-svn: 117403
|
| |
|
|
|
|
| |
so that it's done in one place.
llvm-svn: 117386
|
| |
|
|
| |
llvm-svn: 117328
|
| |
|
|
| |
llvm-svn: 117321
|
| |
|
|
|
|
| |
they can be used outside of the main getTBAAInfo function.
llvm-svn: 117320
|
| |
|
|
|
|
| |
the patch.
llvm-svn: 117159
|
| |
|
|
|
|
|
|
| |
more closely parallel the computation of linkage. This gets us to a state
much closer to what gcc emits, modulo bugs, which will undoubtedly arise in
abundance.
llvm-svn: 117147
|
| |
|
|
|
|
| |
statement expressions, //rdar: //8540501
llvm-svn: 117146
|
| |
|
|
|
|
| |
member expression's base is call expr.
llvm-svn: 117127
|
| |
|
|
| |
llvm-svn: 117120
|
| |
|
|
|
|
|
|
| |
name, otherwise it confuses debugger.
This is tested by local.C in llvmgcc testsuite.
llvm-svn: 117107
|