This patch disables aliasing (and rauw) of derived dtors to base dtors at -O0.
This optimization can have a negative impact on the debug quality.
This was a latent bug for some time with local classes, but got noticed when it
was generalized and broke gdb's destrprint.exp.
llvm-svn: 194618
We already have builtins that are only available in GNU mode, so this
mirrors that.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2128
llvm-svn: 194615
Now that the relevant tests use -mconstructor-aliases and the missing
features have been implemented, we can just drop this.
No functionality change.
llvm-svn: 194595
This allows compilation database implementations for distributed build
systems to hand all data to the client to make parsing independent of
the file system.
llvm-svn: 194571
This adds a new option -fprofile-sample-use=filename to Clang. It
tells the driver to schedule the SampleProfileLoader pass and passes
on the name of the profile file to use.
llvm-svn: 194567
This patch fixes PR8264. Duplicate qualifiers already are diagnozed,
now the same diagnostics is issued for duplicate function specifiers.
Differential Revision: http://llvm-reviews.chandlerc.com/D2025
llvm-svn: 194559
The problem was that given
template<typename T>
struct foo {
~foo() {}
};
template class foo<int>;
We would produce a alias, creating a comdat with D0 and D1, since the symbols
have to be weak. Another TU is not required to have a explicit template
instantiation definition or an explict template instantiation declaration and
for
template<typename T>
struct foo {
~foo() {}
};
foo<int> a;
we would produce a comdat with only one symbol in it.
llvm-svn: 194520
Like GCC, this re-uses the 'f' constraint and a new 'w' print-modifier:
asm ("ldi.w %w0, 1", "=f"(result));
Unlike GCC, the 'w' print-modifer is not _required_ to produce the intended
output. This is a consequence of differences in the internal handling of
the registers in each compiler. To be source-compatible between the
compilers, users must use the 'w' print-modifier.
MSA registers (including control registers) are supported in clobber lists.
llvm-svn: 194476
The xcore llvm backend does not handle 8 byte alignment viz:
"%BadAlignment = alloca i64, align 8"
So getPreferredTypeAlign() must never overalign.
llvm-svn: 194462
The original decls are created when used. The replacements are created at the
end of the TU in reverse order.
This makes the original order far better for testing. This is particularly
important since the replacement logic could be used even when
-mconstructor-aliases is not used, but that would make many tests hard to read.
This is a fixed version of r194357 which handles replacing a destructor with
another which is an alias to a third one.
llvm-svn: 194452
See http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-November/033369.html for discussion on cfe-dev.
This fix explicitly checks whether we are within the declcontext of a lambda's call operator - which is what I had intended to be true (and assumed would be true if getCurLambda returns a valid pointer) before checking whether a lambda can capture the potential-captures of the innermost lambda.
A deeper fix (that addresses why getCurLambda() returns a valid pointer when perhaps it shouldn't?) - as proposed by Richard Smith in http://llvm.org/bugs/show_bug.cgi?id=17877 - has been suggested as a FIXME.
Patch was LGTM'd by Richard (just barely :)
http://llvm-reviews.chandlerc.com/D2144
llvm-svn: 194448
substitution failure, allow a flag to be set on the Diagnostic object,
to mark it as 'causes substitution failure'.
Refactor Diagnostic.td and the tablegen to use an enum for SFINAE behavior
rather than a bunch of flags.
llvm-svn: 194444
Hopefully Richard won't notice this terrible egregiocity - clearly the work of a malevolent poltergeist - fixed now ;)
No functionality change.
llvm-svn: 194439
No Functionality change.
This refactoring avoids having to call getCurLambda right after PushLambdaScope, to obtain the LambdaScopeInfo that was created during the call to PushLambdaScope.
llvm-svn: 194438
The assert this patch deletes was valid only when aliasing D2 to D1, not when
looking at a base class. Since the assert was in the path where we had already
decided to not produce an alias, just drop it.
llvm-svn: 194411
Summary:
Currently with clang:
$ clang -O20 foo.c
error: invalid value '20' in '-O20'
With the patch:
$ clang -O20 foo.c
warning: invalid value '20' in '-O20'. Fall back on value '3'
Reviewers: rengolin, hfinkel
Reviewed By: rengolin
CC: cfe-commits, hfinkel, rengolin
Differential Revision: http://llvm-reviews.chandlerc.com/D2125
llvm-svn: 194403
The original decls are created when used. The replacements are created at the
end of the TU in reverse order.
This makes the original order far better for testing. This is particularly
important since the replacement logic could be used even when
-mconstructor-aliases is not used, but that would make many tests hard to read.
llvm-svn: 194357
clang-cl adds these, so this makes the tests a bit more realistic. These are the
tests where it would make a difference if the windows specific handling were
removed.
llvm-svn: 194336
definition. If we see something that looks like a namespace definition inside a
class, that strongly indicates that a close brace was missing somewhere.
llvm-svn: 194319
It is not safe to emit alias to undefined (not supported by ELF or COFF), but
it is safe to rauw when the alias would have been internal or linkonce_odr.
llvm-svn: 194307
Before, existing code in the form of:
int a; // this is a.
// This is
// b.
int b;
Got turned into:
int a; // this is a.
// This is
// b.
int b;
llvm-svn: 194294
whether we can safely lower a conditional operator to select was insufficient.
I've left a large comment in place to explaining the sort of problems that this
transform can encounter in clang in the hopes of discouraging others from
reimplementing it wrongly again in the future. (The test should also help with
that, but it's easy to work around any single test I might add and think that
your particular implementation doesn't miscompile any code.)
llvm-svn: 194289
Unlike an alias a rauw is always safe, so we don't need to avoid this
optimization when the replacement is not know to be available in every TU.
llvm-svn: 194288
Sublime Text 2 uses Python 2.6
Sublime Text 3 uses Python 3.3
The `print` function has been available as a __future__ import since
2.6, so use it.
Patch by Johan Engelen!
llvm-svn: 194287
This makes it consistent with -fdump-record-layouts, which was moved to
outs() in r186219. My reasoning for going with stdout is that when one
of these options is present, the layouts are really a program output,
and shouldn't be interleaved with diagnostics, which are on stderr.
Reviewers: timurrrr
Differential Revision: http://llvm-reviews.chandlerc.com/D2127
llvm-svn: 194279
Before:
unsigned ContentSize =
sizeof(int16_t) // DWARF ARange version number
+
sizeof(int32_t) // Offset of CU in the .debug_info section
+
sizeof(int8_t) // Pointer Size (in bytes)
+
sizeof(int8_t); // Segment Size (in bytes)
After:
unsigned ContentSize =
sizeof(int16_t) // DWARF ARange version number
+ sizeof(int32_t) // Offset of CU in the .debug_info section
+ sizeof(int8_t) // Pointer Size (in bytes)
+ sizeof(int8_t); // Segment Size (in bytes)
This fixes llvm.org/PR17687.
llvm-svn: 194276
I've added the missing ImutProfileInfo [sic] specialization for bool,
so this patch on r194235 is no longer needed.
This reverts r194244 / 2baea2887dfcf023c8e3560e5d4713c42eed7b6b.
llvm-svn: 194265
Switch clang-format over to Rewriter::overwriteChangedFiles().
The previous implementation was attempting to stream back directly to the
original file and failing if it was already memory mapped by MemoryBuffer,
an operation unsupported by Windows.
MemoryBuffer generally mmaps files larger than the physical page size so
this will have been difficult to reproduce consistently.
This change also reduces flicker in code editors and IDEs on all platforms
when reformatting in-place.
Note that other incorrect uses of MemoryBuffer exist in LLVM/clang and
will need a similar fix.
A test should be added for Windows when libFormat performance issues are
fixed (it takes longer than a day to format a 1MB file at present!)
llvm-svn: 194250
It's better to test clang-check rather than the internal c-index-test utility.
Also adds a target so we can remove the XFAILs.
Thanks to Richard Barton for spotting the test failure on ARM.
Test originally from r193685.
llvm-svn: 194249
A column limit in the test folder can lead to trouble as the RUN, CHECK,
etc. comments can potentially be broken over multiple lines changing
their meaning. Without column limit, clang-format will simply keep the
test author's line breaks.
llvm-svn: 194248
For i686 targets and LLP64 targets, we can see;
error: 'error' diagnostics seen but not expected:
File clang/test/CXX/drs/dr1xx.cpp Line 761: 'check7a' declared as an array with a negative size
File clang/test/CXX/drs/dr1xx.cpp Line 765: 'check8a' declared as an array with a negative size
2 errors generated.
llvm-svn: 194246
In ADT/ImmutableSet, ImutProfileInfo<bool> cannot be matched to ImutProfileInteger.
I didn't have idea it'd the right way if PROFILE_INTEGER_INFO(bool) could be added there.
llvm-svn: 194244
Under ARC++, a reference to a const Objective-C pointer is implicitly
treated as __unsafe_unretained, and can be initialized with (e.g.) a
__strong lvalue. Make sure this behavior does not break template
argument deduction and (related) that partial ordering still prefers a
'T* const&' template over a 'T const&' template when this case kicks
in. Fixes <rdar://problem/14467941>.
llvm-svn: 194239
This syntactic checker looks for expressions on both sides of comparison
operators that are structurally the same. As a special case, the
floating-point idiom "x != x" for "isnan(x)" is left alone.
Currently this only checks comparison operators, but in the future we could
extend this to include logical operators or chained if-conditionals.
Checker by Per Viberg!
llvm-svn: 194236
An Objective-C for-in loop will have zero iterations if the collection is
empty. Previously, we could only detect this case if the program asked for
the collection's -count /before/ the for-in loop. Now, the analyzer
distinguishes for-in loops that had zero iterations from those with at
least one, and can use this information to constrain the result of calling
-count after the loop.
In order to make this actually useful, teach the checker that methods on
NSArray, NSDictionary, and the other immutable collection classes don't
change the count.
<rdar://problem/14992886>
llvm-svn: 194235
The path note that says "Loop body executed 0 times" has been changed to
"Loop body skipped when range is empty" for C++11 for-range loops, and to
"Loop body skipped when collection is empty" for Objective-C for-in loops.
Part of <rdar://problem/14992886>
llvm-svn: 194234
The preprocessor currently recognizes module declarations to load a
module based on seeing the 'import' keyword followed by an
identifier. This sequence is fairly unlikely in C (one would need a
type named 'import'), but is more common in Objective-C (where a
variable named 'import' can cause problems). Since import declarations
currently require a leading '@', recognize that in the preprocessor as
well. Fixes <rdar://problem/15084587>.
llvm-svn: 194225
When performing an Objective-C message send to a value of class type,
perform a contextual conversion to an Objective-C pointer type. We've
had this for a long time, but it recently regressed. Fixes
<rdar://problem/15234703>.
llvm-svn: 194224
As a side-effect, constructors definitions will correctly be recognized
and formatted as function declarations. Tests will be added in a
follow-up patch actually using the correct recognition.
llvm-svn: 194209
Also - others have complained about some white space issues - sorry about that - continues to be a pain point for me - will try and see what I can do with clang-format this evening after work - as a short term fix, if anyone can email me the files that they have already identified with issues, it would help me speed up a focused fix. sorry.
llvm-svn: 194206
Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.
What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.
As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.
Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas. What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.
Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming.
This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
- generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
- nested variadic expansions such as:
auto K = [](auto ... OuterArgs) {
vp([=](auto ... Is) {
decltype(OuterArgs) OA = OuterArgs;
return 0;
}(5)...);
return 0;
};
auto M = K('a', ' ', 1, " -- ", 3.14);
currently cause crashes. I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.
A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!
Now let's hope this commit doesn't upset the buildbot gods ;)
Thanks!
llvm-svn: 194188
limited ways) after the next release. See the lengthy discussions (which
are on-going) and the corresponding commit to LLVM's release notes.
Nothing is actually changing at this point, this is just further
spreading the plan.
llvm-svn: 194184
Summary:
Similar to __FUNCTION__, MSVC exposes the name of the enclosing mangled
function name via __FUNCDNAME__. This implementation is very naive and
unoptimized, it is expected that __FUNCDNAME__ would be used rarely in
practice.
Reviewers: rnk, rsmith, thakis
CC: cfe-commits, silvas
Differential Revision: http://llvm-reviews.chandlerc.com/D2109
llvm-svn: 194181
These allow clients to retrieve persistent AST objects (ASTUnits) which
can be used in an ad-hoc manner after parsing.
To accommodate this change, the code for processing a CompilerInvocation
using a FrontendAction has been factored out to FrontendActionFactory, and
a new base class, ToolAction, has been introduced, allowing the tool to do
arbitrary things with each CompilerInvocation. This change was necessary
because ASTUnit does not use the FrontendAction interface directly.
This change also causes the FileManager in ClangTool to use shared ownership.
This will become necessary because ASTUnit takes shared ownership of
FileManager (ClangTool's FileManager is currently unused by ASTUnit; this
is a FIXME). As shown in the tests, any client of ToolInvocation will
need to be modified to use shared ownership for FileManager.
Differential Revision: http://llvm-reviews.chandlerc.com/D2097
llvm-svn: 194164
On the microsoft ABI clang is producing one weak_odr and one linkonce_odr
destructor, which is reasonable since only one is required.
The fix is simply to move the assert past the special case treatment of
linkonce_odr.
llvm-svn: 194158
These functions can generally be applied to multiple kinds of AST node,
so it makes sense to add them to DynTypedNode.
Differential Revision: http://llvm-reviews.chandlerc.com/D2096
llvm-svn: 194113
The purpose of this function is to allow clients of the dynamic AST matcher
to enumerate each binding.
Differential Revision: http://llvm-reviews.chandlerc.com/D2095
llvm-svn: 194112
NS_RETURNS_INNER_POINTER under -objcmt-returns-innerpointer-property
flag (off by default), as older compilers do not support such annotations.
// rdar://15396636
llvm-svn: 194100
bit more robust against future changes. This includes a slight diagnostic
improvement: if we know we're only trying to form a constant expression, take
the first diagnostic which shows the expression is not a constant expression,
rather than preferring the first one which makes the expression unfoldable.
llvm-svn: 194098
hack of passing -fconst-strings to -cc1, but at least the driver uses
the regular warning checking code path.
Since we don't support a warning that is DefaultIgnore in one language
but not in another, this patch creates a dummy C only warning in the same
group as the existing one to get the desired effect.
llvm-svn: 194097
This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two identical ones.
llvm-svn: 194095
another typo in a comment, and update formatting of some comments to
use Doxygen \brief annotations instead of repeating the name of the
documented entity.
llvm-svn: 194092
Before, clang-format would always format entire nested blocks, which
can be unwanted e.g. for long DEBUG({...}) statements. Also
clang-format would not allow to merge lines in nested blocks (e.g. to
put "if (a) return;" on one line in Google style).
This is the first step of several refactorings mostly focussing on the
additional functionality (by reusing the "format many lines" code to
format the children of a nested block). The next steps are:
* Pull out the line merging into its own class.
* Seperate the formatting of many lines from the formatting of a single
line (and the analysis of the solution space).
llvm-svn: 194090
Turns out this has always been crashing since the test landed in
r186647:
Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function CheckAccessDeclContext, file clang/lib/AST/DeclBase.cpp, line 690.
Needs attention.
llvm-svn: 194072
llc waits for input on stdin, which was not provided in this test. It
was running only thanks to a quirk in the way lit concatenates
commands.
llvm-svn: 194071
After lexing a '##', we would look ahead and check to see if it was
followed by '__VA_ARGS__'. After doing so, we would then go ahead and
lex the token.
However we would fail in the case where the '##' was followed by a '#'
followed by an identifier because we would have lexed the '#' separately
from the identifier, bypassing our parameter validation logic.
Instead, lex the tokens coming after the '##' later.
This fixes PR17804.
llvm-svn: 194059
Rafael Espindola