This is a testcase for r209227, a change in LLVM that automatically sets
visibility to default when the linkage is changed to local (rather than
asserting).
What this testcase triggers is hard to reproduce otherwise: the
`GlobalValue` is created (with non-local linkage), the visibility is set
to hidden, and then the linkage is set to local.
PR19760
llvm-svn: 209228
This is a GNU attribute that causes calls within the attributed function
to be inlined where possible. It is implemented by giving such calls the
alwaysinline attribute.
Differential Revision: http://reviews.llvm.org/D3816
llvm-svn: 209217
For targeting i686-msvc, declarations are seen as thiscall like;
void (template_test::S::*)(const int &) __attribute__((thiscall))
void (template_test::S::*)(int) __attribute__((thiscall))
It didn't affect x86_64-msvc.
llvm-svn: 209212
The attribute emitter was using FunctionTemplate to map the diagnostic to "functions or methods", but that isn't a particularly clear diagnostic in these cases anyway (since they do not apply to ObjC methods). Updated the attribute emitter to remove custom logic for FunctionTemplateDecl, and updated the test cases for the change in diagnostic wording.
llvm-svn: 209209
It appears that Windows doesn't like renaming over open files, which we
do in clearOutputFiles. The file being compiled should be safe to
removed, but this isn't very satisfying - we don't want to manually
manage the lifetime of files we cannot prove have no references.
llvm-svn: 209195
behavior on mismatch. The AutoUpgrader will drop incompatible debug info
any way and also emit a warning diagnostic for it.
rdar://problem/16926122
llvm-svn: 209182
The -no-ns-alloc-error migration option now causes the diagnostic to be ignored
completely. If this isn't desired, the error can be downgraded to a warning
using the usual -Wno-error=arcmt-ns-alloc.
Note that we can't use -verify right now on this test because
VerifyDiagnosticConsumer gets confused by multiple SourceManager instances,
which is presumably the reason it was XFAILed in the first place and why the
regression wasn't detected. We'll grep instead for now.
llvm-svn: 209172
This is a GNU attribute that allows split stacks to be turned off on a
per-function basis.
Differential Revision: http://reviews.llvm.org/D3817
llvm-svn: 209167
declaration of that entity in from one of those modules, keep track of the fact
that we've not completed the redeclaration chain yet so that we can pull the
remaining declarations in from the other module if they're needed.
llvm-svn: 209161
This patch implements global named registers in Clang, lowering to the just
created intrinsics in LLVM (@llvm.read/write_register). A new type of LValue
had to be created (Register), which just adds support to carry the metadata
node containing the name of the register. Two new methods to emit loads and
stores interoperate with another to emit the named metadata node.
No guarantees are being made and only non-allocatable global variable named
registers are being supported. Local named register support is unchanged.
llvm-svn: 209149
We only need them on the dllimport.cpp test to make sure that we emit code
for available_externaly functions, and don't inline the IR.
llvm-svn: 209145
Follow-up fix for 209138. Actually, since we already have this file
open, we don't want to refresh the stat() info, since that might be
newer than what we have open (bad!).
llvm-svn: 209143
FileManager::invalidateCache is not safe to call when there may be
existing references to the file. What module load failure needs is
to refresh so stale stat() info isn't stored.
This may be the last user of invalidateCache; I'll take a look and
remove it if possible in a future commit.
This caused a use-after-free error as well as a spurious error message
that a module was "found in both 'X.pcm' and 'X.pcm'" in some cases.
llvm-svn: 209138
The list of alpha and the list of implicit checkers added. An ability to expand/collapse long texts added. Markup fixed.
http://reviews.llvm.org/D3457
llvm-svn: 209131
When we were padding a struct to avoid splitting it between registers and
the stack, we were throwing away the type which the argument should be coerced
to.
llvm-svn: 209122
r179585 introduced different MSPropertyRefExpr visitation for RAV and DRAV that
appears to have been unintentional. Let's use the more complete one.
llvm-svn: 209101
* Shuffle around code to reduce delta between the two RAVs.
* Merge r189185 that was applied only to one of the RAVs and became apparent during the unification work.
* Fix Enqueue data recursion typo.
Our delta is down to +-579!
llvm-svn: 209093
Apply current ToT clang-format on the two RAVs to reduce delta and help
identify differences between the two.
We lose a little pretty formatting in the headers but that's the price to pay
so we can diff these two files effectively and look to a future where we don't
have to maintain two copies of this code.
Formatting and whitespace only.
llvm-svn: 209092
Define a macro to reduce the delta between RecursiveASTVisitor and
DataRecursiveASTVisitor.
Some years ago, someone thought it was a good idea to copy the entire RAV to
support cursor visitation in libclang.
Since then the two have diverged needlessly and the rest is history.
This series of commits aims to reduce delta between the two so that we can
reason about their differences, apply bugfixes that were only made to one but
not the other, and ultimately find a way to unify two two chunks of code.
llvm-svn: 209091
Windows on ARM expects ARMv8 (restricted IT) conditional instructions only.
Force enable the restricted IT mode via the backend option when targeting WoA.
llvm-svn: 209086
These are now treated as environments. Remove references to these enumeration
values in order to clean up the unused enumeration entries in LLVM. The target
normalisation prior to tool invocation should ensure that the old values
continue to function properly.
llvm-svn: 209068
The conventional form is '<action> to silence this warning'.
Also call the diagnostic an 'issue' rather than a 'message' because the latter
term is more widely used with reference to message expressions.
llvm-svn: 209052
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
llvm-svn: 209046
Now that llvm cannot represent alias cycles, we have to diagnose erros just
before trying to close the cycle. This degrades the errors a bit. The real
solution is what it was before: if we want to provide good errors for these
cases, we have to be able to find a clang level decl given a mangled name
and produce the error from Sema.
llvm-svn: 209008
If `-shared` is specified, pull in a PIC-version of the profile runtime,
which was added to compiler-rt in r208947. I'm hoping this will get the
bots on my side.
llvm-svn: 208948
Shared objects are fairly broken for InstrProf right now -- a follow-up
commit in compiler-rt will fix the rest of this.
The main problem here is that at link time, profile data symbols in the
shared object might get used instead of symbols from the main
executable, creating invalid profile data sections.
<rdar://problem/16918688>
llvm-svn: 208939
This allows us to perfectly forward non-trivial arguments that use
inalloca.
We still can't forward non-trivial arguments through thunks when we have
a covariant return type with a non-trivial adjustment. This would
require emitting an extra copy, which is non-conforming anyway.
llvm-svn: 208927
All callers were passing in "a.out" or garbage so a sensible default works fine
here as a cleanup.
This also brings about the possibility of adapting the value based on the
driver's compatibility mode in future.
The setting can still be changed via Driver::DefaultImageName as needed.
llvm-svn: 208926
When using the VFS, we want the virtual header location when searching
for a framework module, since that will be the one in the correct
directory structure for the module.
I'll add a regression test once I finish reducing the larger one I have.
llvm-svn: 208901
GetGVALinkageForFunction handles TSK_ExplicitInstantiationDeclaration
twice, remove the redundant code trying to handle it again.
While we are here, update the reference we make to the standard. It
seems like another paragraph was added causing this text to get
renumbered.
llvm-svn: 208850
This undoes half of r208786.
It had problems with lazily declared special members in cases like this:
struct A {
A();
A &operator=(A &&o);
void *p;
};
void foo(A);
void bar() {
foo({});
}
In this case, the copy and move constructors are implicitly deleted.
However, Clang doesn't eagerly declare the copy ctor in the AST, so we
pass the struct in registers. Furthermore, GCC passes this in registers
even though this class should be uncopyable.
Revert this for now until the dust settles.
llvm-svn: 208836
This affects both the Itanium and Microsoft C++ ABIs.
This is in anticipation of a change to the Itanium C++ ABI, and should
match GCC's current behavior. The new text will likely be:
"""
Pass an object of class type by value if every copy constructor and
move constructor is deleted or trivial and at least one of them is not
deleted, and the destructor is trivial.
"""
http://sourcerytools.com/pipermail/cxx-abi-dev/2014-May/002728.html
On x86 Windows, we can mostly use the same logic, where we use inalloca
instead of passing by address. However, on Win64, there are register
parameters, and we have to do what MSVC does. MSVC ignores the presence
of non-trivial move constructors and only considers the presence of
non-trivial or deleted copy constructors. If a non-trivial or deleted
copy ctor is present, it passes the argument indirectly.
This change fixes bugs and makes us more ABI compatible with both GCC
and MSVC.
Fixes PR19668.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3660
llvm-svn: 208786
This looks like the right way for this check to work, but there is
another semi-obvious bug, I would think: why is CurLoc not zero'd out
between functions? The possibility for it to bleed between them seems
problematic. (& indeed I caused tests to fail when I fixed this a
different way, by setting CurLoc to SourceLocation() and the end of
EmitFunctionEnd... )
The changes to debug-info-blocks.m are due to a mismatch between the
source manager's file naming and CGDebugInfo's default handling when no
-main-file-name is specified. This actually reveals somewhat of a bug in
the debug info when using source files from standard in, too. See the
comment in CGDebugInfo::CreateCompileUnit for more details.
llvm-svn: 208742
In the Microsoft C++ ABI, instance methods always return records
indirectly via the second hidden parameter. This was implemented in
X86_32ABIInfo, but not WinX86_64ABIInfo.
Rather than exposing a handful of boolean methods in the CGCXXABI
interface, we can expose a single method that applies C++ ABI return
value classification rules.
llvm-svn: 208733
caused us to perform copy-initialization for the parameters of an allocation
function called by a new-expression multiple times, resulting in us rejecting
allocations that passed non-copyable parameters (and much worse things in
MSVC compat mode, where we potentially called this function multiple times).
llvm-svn: 208724
`clang -S -o - file.c -masm=att` will write assembly to stdout in at&t syntax
(the default), `-masm=intel` will instead output intel style asm.
llvm-svn: 208683
Summary:
Most of the clang header patch by Simon Pilgrim @ SCEE.
Also fixed (or added) clang tests for these intrinsics.
LLVM tests to make sure we get the blend instruction out of these
shufflevectors are at http://reviews.llvm.org/D3600
Reviewers: eli.friedman, craig.topper, rafael
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3601
llvm-svn: 208664
Implement what we currently believe is the mangling scheme for RTTI
data. Tests will be added in a later commit which actually generate
RTTI data.
llvm-svn: 208661
source that provides a declaration from a hidden module would not have the
visibility of the produced definition checked. This might matter if an
external source chose to import a new module to provide an extra definition,
but is not observable with our current external sources.
llvm-svn: 208659
asan_cxx containts replacements for new/delete operators, and should
only be linked in C++ mode. We plan to start building this part
with exception support to make new more standard-compliant.
See https://code.google.com/p/address-sanitizer/issues/detail?id=295
for more details.
llvm-svn: 208610
iterating over different library path suffixes and different library versions.
To find the most appropriate library for the given command line flags we
iterate over a set of disk paths. Before probe each path the already
detected set of multilibs are cleared. If the set of paths contains
existing paths which do not satisfy command line flags or do not contain
necessary libraries and object files at all we might lose found multilibs.
The patch updates variables which hold detected multilibs if we really find
a new multilib matches command line flags.
The patch reviewed by Jon Roelofs.
llvm-svn: 208523
Add ARM support for dllexport and dllimport attributes. This is a relatively
conservative change. The alternative is to entirely drop the architecture
requirement. The dllimport and dllexport attributes are not restricted to any
architecture, simply to platforms that support this attribute (currently
Windows).
llvm-svn: 208486
The loop body used to contain a switch statement; it looks like r96685 replaced
that with an if/else if/else but accidentally left one of the three break
statements from the switch behind, skipping the clang_disposeString() call
for replacements (and the rest of the loop too, which apparently doesn't make
a differences for the test cases we have).
r96685: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100215/027754.html
This too might possibly the last leak in clang (PR19521).
llvm-svn: 208483
Fixes PR19689, and possibly the last leak in clang (PR19521). PR19689 contains
a few suggestions on how to make the default argument token code a bit more
solid, these changes can possibly be landed in follow-ups.
llvm-svn: 208481
Also tidy up, simplify, and extend the test coverage to demonstrate the
limitations. This test should now fail if the bugs are fixed (&
hopefully whoever ends up in this situation sees the FIXMEs and realizes
that the test needs to be updated to positively test their change that
has fixed some or all of these issues).
I do wonder whether I could demonstrate breakage without a macro here,
but any way I slice it I can't think of a way to get two calls to the
same function on the same line/column in non-macro C++ - implicit
conversions happen at the same location as an explicit function, but
you'd never get an implicit conversion on the result of an explicit call
to the same implicit conversion operator (since the value is already
converted to the desired result)...
llvm-svn: 208468
Summary:
MSVC always passes 'sret' after 'this', unlike GCC. This required
changing a number of places in Clang that assumed the sret parameter was
always first in LLVM IR.
This fixes win64 MSVC ABI compatibility for methods returning structs.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3618
llvm-svn: 208458
r144269 changed clang_disposeDiagnostic() to be a no-op, but didn't update
code completion diagnostics. Let CXCodeCompleteResults store all diagnostics
returned by clang_codeCompleteGetDiagnostic() and then free them up in
clang_disposeCodeCompleteResults().
Code completion diagnostics referred to data stored in CXCodeCompleteResults
before already, so it wasn't possible to refer to the results of
clang_codeCompleteGetDiagnostic() after clang_disposeCodeCompleteResults()
before this change already -- hence this should be a safe, backwards-compatible
change.
Leak found by LSan, fixes PR19690.
llvm-svn: 208454
The base class is the culprit/risk here - a sealed/final derived class
with virtual functions and a non-virtual dtor can't accidentally be
polymorphically destroyed (if the base class's dtor is protected - which
also suppresses this warning).
llvm-svn: 208449
MacroArgs are owned by TokenLexer, and when a TokenLexer is destroyed, it'll
call its MacroArgs's destroy() method. destroy() only appends the MacroArg to
Preprocessor's MacroArgCache list, and Preprocessor's destructor then calls
deallocate() on all MacroArgs in that list. This method then ends up freeing
the MacroArgs's memory.
In a code completion context, Parser::cutOffParsing() gets called when a code
completion token is hit, which changes the type of the current token to
tok::eof. eof tokens aren't always ConsumeToken()ed, so
Preprocessor::HandleEndOfFile() isn't always called, and that function is
responsible for popping the macro stack.
Due to this, Preprocessor::CurTokenLexer can be non-NULL when
~Preprocessor runs. It's a unique_ptr, so it ended up being destructed after
~Preprocessor completed, and its MacroArgs thus got added to the freelist after
the code freeing things on the freelist had already completed. The fix is to
explicitly call reset() before the freelist processing happens. (See the bug
for more notes.)
llvm-svn: 208438
The thread safety analysis isn't very useful in ObjC (you can't annotate
ObjC classes or methods) but we can still analyze the actual code and
show violations in usage of C/C++ functions.
Fixes PR19541, which does not use thread safety attributes but crashes
with -Weverything.
llvm-svn: 208436
This is the clang counterpart to 208413, which ensures that Homogeneous
Floating-point Aggregates are passed in consecutive registers on ARM.
llvm-svn: 208417
This lets us diagnose and perform more complete semantic analysis when faced
with errors in the function body or declaration.
By recovering here we provide more consistent diagnostics, particularly during
interactive editing.
llvm-svn: 208394
Eric Christopher