lit.cfg has never supported running .C files, so these tests were never
executed by check-clang. Rename them to .cpp so that they run as part of
the test suite, and minorly tweak two of them that look like they were broken
when checked in to actually pass.
llvm-svn: 227029
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
Only the first two items for now, changing Sections 8.5.4 [dcl.init.list] paragraph 3 and 13.3.1.7 [over.match.list] paragraph 1,
so that defining class objects and character arrays using uniform initialization syntax is actually treated as list initialization
and before it is treated aggregate initialization.
llvm-svn: 227022
and only update the orginal list on a valid arugment list. When checking an
individual expression template argument, and conversions are required, update
the expression in the template argument. Since template arguments are
speculatively checked, the copying of the template argument list prevents
updating the template arguments when the list does not match the template.
Additionally, clean up the integer checking code in the template diffing code.
The code performs unneccessary conversions from APSInt to APInt.
Fixes PR21758.
This essentially reverts r224770 to recommits r224667 and r224668 with extra
changes to prevent the template instantiation problems seen in PR22006.
A test to catch the discovered problem is also added.
llvm-svn: 226983
encountered any definition for the class; this happens when the definition is
added by an update record that is not yet loaded. In such a case, eagerly pick
the original parent of the member as the canonical definition of the class
rather than muddling through with the canonical declaration (the latter can
lead to us failing to merge properly later if the canonical definition turns
out to be some other declaration).
llvm-svn: 226977
In ItaniumCXXABI::EmitCXXDestructors we first emit the base destructor
and then try to emit the complete one as an alias.
If in the base ends up calling the complete destructor, the GD for the
complete will be in the list of deferred decl by the time we replace
it with an alias and delete the original GV.
llvm-svn: 226896
* Put all input files under Inputs/, move corresponding tests into test/Modules.
* Rename a modulemap test file to [...].modulemap, and teach lit that such files are tests.
llvm-svn: 226875
"omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform
an atomic load of "x" (using builtin atomic loading instructions or a call to
"atomic_load()" for simple lvalues and "kmpc_atomic_start();load
<x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to
type of "v" (using EmitScalarConversion() for simple types and
EmitComplexToScalarConversion() for conversions from complex to scalar) and then
store the result in "v".)
Differential Revision: http://reviews.llvm.org/D6431
llvm-svn: 226788
"omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform
an atomic load of "x" (using builtin atomic loading instructions or a call to
"atomic_load()" for simple lvalues and "kmpc_atomic_start();load
<x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to
type of "v" (using EmitScalarConversion() for simple types and
EmitComplexToScalarConversion() for conversions from complex to scalar) and then
store the result in "v".)
Differential Revision: http://reviews.llvm.org/D6431
llvm-svn: 226786
"omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform
an atomic load of "x" (using builtin atomic loading instructions or a call to
"atomic_load()" for simple lvalues and "kmpc_atomic_start();load
<x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to
type of "v" (using EmitScalarConversion() for simple types and
EmitComplexToScalarConversion() for conversions from complex to scalar) and then
store the result in "v".
Differential Revision: http://reviews.llvm.org/D6431
llvm-svn: 226784
record, and that class declaration is not the canonical definition of the
class, be sure to add the class to the list of classes that are consulted when
we look up a special member in the canonical definition.
llvm-svn: 226778
on top of a local declaration of the same entity, we still need to remember
that we loaded the first one or we may fail to merge the second one properly.
llvm-svn: 226765
We don't emit any coverage mapping for uncovered functions that come
from system headers, but we were creating a GlobalVariable with each
of their names. This is wasteful since the linker will need to dead
strip the unused symbols, and it can lead to issues when merging
coverage with others TUs that do have coverage for those functions.
llvm-svn: 226764
load the definition data from the declaration itself. In that case, merge
properly; don't assume the prior definition is the same as our own.
llvm-svn: 226761
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad
normal:
store i32 %rr, i32* %r
ret i1 1
lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume
eh.except:
ret i1 false
eh.resume:
resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
It fails on Windows due to another temporary being emitted first, so the
LLVM internal renaming scheme gives out the name
__block_descriptor_tmp1.
llvm-svn: 226757
Importing _Builtin_intrinsics.sse and avx would transitively pull in those
headers, and the test would fail when building in an environment where
they were not available on the include path.
This fixes PR20995 for me.
Differential Revision: http://reviews.llvm.org/D7112
llvm-svn: 226754
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
llvm-svn: 226751
This test will start failing shortly once this bug is fixed in LLVM. At
that point this behavior is no longer required in Clang and will be
removed. In the interim, remove this test just to avoid the race between
the LLVM and Clang commits.
After the LLVM commit, I'll cleanup the workaround behavior in Clang.
llvm-svn: 226735
This attribute implies indicates that the function musttail calls
another function and returns whatever it returns. The return type of the
thunk is meaningless, as the thunk can dynamically call different
functions with different return types. So long as the callers bitcast
the thunk with the correct type, behavior is well defined.
This attribute was necessary to fix PR20944, where the indirect call
combiner noticed that the thunk returned void and replaced the results
of the indirect call instruction with undef.
Over-the-shoulder reviewed by David Majnemer.
llvm-svn: 226707
The improved completion in call context now works with:
- Functions.
- Member functions.
- Constructors.
- New expressions.
- Function call expressions.
- Template variants of the previous.
There are still rough edges to be fixed:
- Provide support for optional parameters. (fix known)
- Provide support for member initializers. (fix known)
- Provide support for variadic template functions. (fix unknown)
- Others?
llvm-svn: 226670
We didn't consider any alignment attributes on an EnumDecl when
calculating alignment.
While we are here, ignore alignment specifications on typedef types if
one is used as the underlying type. Otherwise, weird things happen:
enum Y : int;
Y y;
typedef int __attribute__((aligned(64))) u;
enum Y : u {};
What is the alignment of 'Y'? It would be more consistent with the
overall design of enums with fixed underlying types to consider the
underlying type's UnqualifiedDesugaredType.
This fixes PR22279.
llvm-svn: 226653
be corrected.
This fixes PR22250, which exposed the bug where if there's more than one
TypoExpr in the arguments, once one failed to be corrected none of the
TypoExprs after it would be handled at all thanks to an early return.
llvm-svn: 226624
The test case is based on the reduction from PR21679 and has to be
freestanding to work correctly, since some of the expected errors (and
some of the problems that were fixed) only occur when the end of the
file is reached.
llvm-svn: 226603
The test was fixed after a discussion with the revision author: the check
pattern was made more flexible as the "%call" part is not what we actually want
to check strictly there.
The original patch description:
===
Introduce SPIR calling conventions.
This implements Section 3.7 from the SPIR 1.2 spec:
SPIR kernels should use "spir_kernel" calling convention.
Non-kernel functions use "spir_func" calling convention. All
other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
===
llvm-svn: 226561
This implements Section 3.7 from the SPIR 1.2 spec:
SPIR kernels should use "spir_kernel" calling convention.
Non-kernel functions use "spir_func" calling convention. All
other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
llvm-svn: 226548
Analogous to AVX2, these need to be implemented as macros to properly
propagate the immediate index operand.
Part of <rdar://problem/17688758>
llvm-svn: 226496
Things that are OK:
extern int var1 __attribute((alias("v1")));
static int var2 __attribute((alias("v2")));
Things that are not OK:
int var3 __attribute((alias("v3")));
extern int var4 __attribute((alias("v4"))) = 4;
We choose to accpet:
struct S { static int var5 __attribute((alias("v5"))); };
This code causes assertion failues in GCC 4.8 and ICC 13.0.1, we have
no reason to reject it.
This partially fixes PR22217.
llvm-svn: 226436
If an unscoped enum is used as a nested name specifier and the language dialect
is not C++ 11, issue an extension warning.
This fixes PR16951.
Differential Revision: http://reviews.llvm.org/D6389
llvm-svn: 226413
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.
llvm-svn: 226410
This was causing some trouble for otherwise dead code removed in r225085
(reverted in r225361). The location being set for function arguments was
leaking out to the call which wasn't setting its own location (so a
quality bug turned into a crasher with r225085). Fix this so r225085 can
be recommitted.
llvm-svn: 226382
Clang currently crashes on
class C {
C() = default;
C() = delete;
};
My cunning plan for fixing this was to change the `if (!FnD)` in
Parser::ParseCXXInlineMethodDef() to `if (!FnD || FnD->isInvalidDecl)` – but
alas, the second constructor decl wasn't marked as invalid. This lets
Sema::MergeFunctionDecl() return true on function redeclarations, which leads
to them being marked invalid.
This also improves error messages when functions are redeclared.
llvm-svn: 226365
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
llvm-svn: 226340
As mentioned in the previous commit, if a property (declared with @property)
has a name that matches a special Objective-C method family, the getter picks
up that family despite being declared by the property. The most correct way
to solve this problem is to add the 'objc_method_family' attribute to the
getter with an argument of 'none', which unfortunately requires an explicit
declaration of the getter.
This commit adds a note to the existing error (ARC) or warning (MRR) for
such a poorly-named property that suggests the solution; if there's already
a declaration of the getter, it even includes a fix-it.
llvm-svn: 226339
Two years ago I added a compile-time "optimization" to
ObjCMethodDecl::findPropertyDecl: exit early if the current method is part
of a special Objective-C method family (like 'new' or 'init'). However, if a
property (declared with @property) has a name that matches a method family,
the getter picks up that family despite being declared by the property. The
early exit then made ObjCMethodDecl::findPropertyDecl decide that there
was no associated property, despite the method itself being marked as an
accessor. This corrects that by removing the early exit.
This does /not/ change the fact that such a getter is considered to return a
value with a +1 retain count. The best way to eliminate this is by adding the
objc_method_family(none) attribute to the getter, but unlike the existing
ns_returns_not_retained that can't be applied directly to the property -- you
have to redeclare the getter instead.
(It'd be nice if @property just implied objc_method_family(none) for its
getter, but that would be a backwards-incompatible change.)
rdar://problem/19038838
llvm-svn: 226338
Emitting inlinable calls without debug locations (in functions with
debug info, to functions with debug info) is problematic for debug info
when inlining occurs. Test specifically that we don't do that in this
case - thus the test isn't simply "don't crash", it's "include debug
location for this call" (granted it's the wrong location - fix for that
is coming)
llvm-svn: 226337
ambiguity but wasn't.
In the new test case, "click" wasn't being corrected properly because
Sema::ClassifyName would call CorrectTypo for "click" then later
Sema::DiagnoseEmptyLookup would call CorrectTypoDelayed for the same use
of "click" (the former by the parser needing to determine what the
identifier is so it knows how to parse the statement, i.e. is it the
beginning of a declaration or an expression). CorrectTypo would record
that typo correction for "click" failed and CorrectTypoDelayed would see
that and not even try to correct the typo, even though in this case
CorrectTypo failed due to an ambiguity (both "Click" and "clock" having
an edit distance of one from "click") that could be resolved with more
information. The fix is two-fold:
1) Have CorrectTypo not record failed corrections if the reason for
the failure was two or more corrections with the same edit
distance, and
2) Make the CorrectionCandidateCallback used by
Parser::ParseCastExpression reject FunctionDecl candidates when the
next token after the identifier is a ".", "=", or "->" since
functions cannot be assigned to and do not have members that can be
referenced.
The reason for two correction spots is that from r222549 until r224375
landed, the first correction attempt would fail completely but the
second would suggest "clock" while having the note point to the
declaration of "Click".
llvm-svn: 226334
There was already an explicit check for that for the first decl. Move that
to a different place so that it's called for the following decls too. Also
don't randomly set the BitfieldSize ExprResult to true (this sets a pointer to
true internally).
Found by SLi's bot.
llvm-svn: 226306
NAKAMURA Takumi