Create a new TargetCodeGenInfo for Windows on ARM to permit annotating the
functions with stack-probe-size (for /Gs and -mstack-probe-support) for
generating the stack probe necessary for Windows targets. This will be used by
the backend when lowering the frame to generate the stack probe appropriately.
Nico Weber [Fri, 30 Jan 2015 16:53:11 +0000 (16:53 +0000)]
Follow-up to r217302 and r227555: Don't crash on inline ~A::A() if A is an int.
Even with r227555, this still crashed:
struct S {
int A;
~A::A() {}
};
That's because ParseOptionalCXXScopeSpecifier()'s call to
ActOnCXXNestedNameSpecifier() doesn't mark the scope spec as invalid if sema
thought it's a good idea to fixit-correct "::" to ":". For the diagnostic
improvement done in r217302, we never want :: to be interpreted as :, so fix
this by setting ColonSacred to false temporarily.
Fraser Cormack [Fri, 30 Jan 2015 10:51:46 +0000 (10:51 +0000)]
Fix OpenCL 1.2 double as an optional core feature behaviour
In OpenCL 1.2, using double no longer requires using the pragma cl_khr_fp64,
instead a kernel is allowed to use double, but must first have queried
clGetDeviceInfo's CL_DEVICE_DOUBLE_FP_CONFIG.
Page 197, section 6.1.1 of the OpenCL 1.2 specification has a footnote 23
describing this behaviour.
I've also added test cases such that the pragma must be used if targeting
OpenCL 1.0 or 1.1, but is ignored in 1.2 and 2.0.
David Majnemer [Fri, 30 Jan 2015 05:01:23 +0000 (05:01 +0000)]
Sema: Disable template instantiation once a fatal error is raised
Fatal errors disable all further diagnostics. Continuing to permit
template instantiation does nothing but make it take longer for clang to
finish with the TU.
Ulrich Weigand [Thu, 29 Jan 2015 19:08:51 +0000 (19:08 +0000)]
[PowerPC] Work around TLS linker bug
Work around a bug in GNU ld (and gold) linker versions up to 2.25
that may mis-optimize code generated by this version of clang/LLVM
to access general-dynamic or local-dynamic TLS variables.
Bug is fixed here:
https://sourceware.org/ml/binutils/2015-01/msg00318.html
Rafael Espindola [Thu, 29 Jan 2015 17:22:53 +0000 (17:22 +0000)]
This reverts commit r227432, r227438 and r227448.
It should bring the bots back.
Original messagses:
r227448:
Remove unnecessary default.
r227438:
Fix Index/print-type.cpp test following r227432.
r227432:
libclang: Add three functions useful for dealing with anonymous fields:
clang_Cursor_getOffsetOfField
clang_Cursor_isAnonymous
clang_Type_visitFields
Python: Add corresponding methods for dealing with anonymous fields.
Aaron Ballman [Thu, 29 Jan 2015 16:58:53 +0000 (16:58 +0000)]
Reverting r227453, which adds back the fuzzer library. Now excluding the clang-format fuzzer functionality based on LLVM_USE_SANITIZE_COVERAGE being set or unset.
Francois Pichet [Thu, 29 Jan 2015 12:45:29 +0000 (12:45 +0000)]
libclang: Add three functions useful for dealing with anonymous fields:
clang_Cursor_getOffsetOfField
clang_Cursor_isAnonymous
clang_Type_visitFields
Python: Add corresponding methods for dealing with anonymous fields.
David Majnemer [Thu, 29 Jan 2015 09:29:21 +0000 (09:29 +0000)]
MS ABI: Implement proper support for setjmp
On targets which use the MSVCRT, setjmp is a macro which expands to
_setjmp or _setjmpex.
_setjmp and _setjmpex have a secret, hidden argument which is not listed
in the function prototype on X64 and WoA. This hidden argument always
seems to be the frame pointer.
_setjmpex isn't used on X86, _setjmp is magically replaced with a call
to _setjmp3. The second argument is zero for 'normal' setjmp/longjmp
pairs, otherwise it is a count of additional variadic arguments. This
is used when setjmp appears inside of a try or __try.
It is not safe to use a pointer to setjmp because _setjmp, _setjmpex and
_setmp3 are not compatible with setjmp.
For the --be8 flag, check explicitly for pre-v7 / pre-v6m cores.
Those used the old Big Endian support on ARM and don't need flags.
Refactor the logic in a separate common function, which also looks at
-march. Add corresponding logic for the Linux toolchain.
Richard Smith [Wed, 28 Jan 2015 22:06:01 +0000 (22:06 +0000)]
PR22367: Don't forget to create a CXXFunctionalCastExpr around
list-initialization that gets converted to some form other than an
InitListExpr. CXXTemporaryObjectExpr is a special case here, because it
represents a fused CXXFunctionalCastExpr + CXXConstructExpr. That, in
itself, is probably a design error...
Kaelyn Takata [Wed, 28 Jan 2015 21:10:46 +0000 (21:10 +0000)]
Revert a change from r222797 that is no longer needed and can cause
infinite recursion.
Also guard against said infinite recursion by adding an assert that will
trigger if CorrectDelayedTyposInExpr is called before a previous call to
CorrectDelayedTyposInExpr returns (i.e. if the TreeTransform run by
CorrectDelayedTyposInExpr calls a sequence of methods that
end up calling CorrectDelayedTyposInExpr, as the new test case had done
prior to this commit). Fixes PR22292.
Derek Schuff [Wed, 28 Jan 2015 20:24:52 +0000 (20:24 +0000)]
Remove support for pnaclcall attribute
Summary:
It was used for interoperability with PNaCl's calling conventions, but
it's no longer needed.
Also Remove NaCl*ABIInfo which just existed to delegate to either the portable
or native ABIInfo, and remove checkCallingConvention which was now a no-op
override.
David Blaikie [Wed, 28 Jan 2015 19:50:09 +0000 (19:50 +0000)]
DebugInfo: Attribute implicit boolean tests to the expression being tested, not to the outer use of that expression.
This is half a fix for a GDB test suite failure that expects to start at
'a' in the following code:
void func(int a)
if (a
&&
b)
...
But instead, without this change, the comparison was assigned to '&&'
(well, worse actually - because there was a chained 'a && b && c' and it
was assigned to the second '&&' because of a recursive application of
this bug) and then the load folded into the comparison so breaking on
the function started at '&&' instead of 'a'.
The other part of this needs to be fixed in LLVM where it's ignoring the
location of the icmp and instead using the location of the branch
instruction.
The fix to the conditional operator is actually a no-op currently,
because the conditional operator's location coincides with 'a' (the
start of the conditional expression) but should probably be '?' instead.
See the FIXME in the test case that mentions the ARCMigration tool
failures when I tried to make that change.
Sean Silva [Wed, 28 Jan 2015 14:19:08 +0000 (14:19 +0000)]
Avoid testing for a particular choice of resource dir.
Without this patch, this test was accidentally testing that
CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING
were set to a particular set of values.
The test was also getting pretty hairy since it was attempting to craft
a regular expression that covered "all" possible combinations of
settings for these configure-time constants.
Clean it up by directly capturing the resource directory in a FileCheck
variable.
The code building the code completion string for overloads was providing
less detail compared to the one building completion strings for function
declarations. There was no information about optionals and no information
about what's a parameter and what's a function identifier, everything
besides ResultType, CurrentParameter and special characters was classified
as Text.
This makes code completion strings for overload candidates to follow a
pattern very similar, but not identical, to the one in use for function
declarations:
- return type chunk: ResultType
- function identifier chunk: Text
- parameter chunks: Placeholder
- optional parameter chunks: Optional
- current parameter chunk: CurrentParameter
Kaelyn Takata [Wed, 28 Jan 2015 00:46:09 +0000 (00:46 +0000)]
Use the real CXXScopeSpec when setting the correction SourceRange.
Otherwise, in the most important case and the only case where SS and
TempSS are different (which is when the CXXScopeSpec should be dropped,
and TempSS is NULL) the wrong SourceRange will be used in the fixit for
the typo correction. Fixes the remaining issue in PR20626.
Kaelyn Takata [Tue, 27 Jan 2015 22:01:39 +0000 (22:01 +0000)]
Fix a think-o in handling ambiguous corrections for a TypoExpr.
Under certain circumstances, the identifier mentioned in the diagnostic
won't match the intended correction even though the replacement
expression and the note pointing to the decl are both correct.
Basically, the TreeTransform assumes the TypoExpr's Consumer points to
the correct TypoCorrection, but the handling of typos that appear to be
ambiguous from the point of view of TransformTypoExpr would cause that
assumption to be violated by altering the Consumer's correction stream.
This fix allows the Consumer's correction stream to be reset to the
right TypoCorrection after successfully resolving the percieved ambiguity.
Included is a fix to suppress correcting the RHS of an assignment to the
LHS of that assignment for non-C++ code, to prevent a regression in
test/SemaObjC/provisional-ivar-lookup.m.
Larisse Voufo [Tue, 27 Jan 2015 18:47:05 +0000 (18:47 +0000)]
Implement the remaining portion of DR1467 from r227022. I may have overlooked a few things, but this implementation comes straight from the DR resolution itself.
Kaelyn Takata [Tue, 27 Jan 2015 18:26:18 +0000 (18:26 +0000)]
Properly handle typos in the conditional of ?: expressions in C.
In particular, remove the OpaqueExpr transformation from r225389 and
move the correction of the conditional from CheckConditionalOperands to
ActOnConditionalOp before the OpaqueExpr is created. This fixes the
typo correction behavior in C code that uses the GNU extension for a
binary ?: (without an expression between the "?" and the ":").
Richard Smith [Tue, 27 Jan 2015 03:30:40 +0000 (03:30 +0000)]
DR1902: if overload resolution recurses, and the inner overload resolution
selects a deleted function, the outer function is still a candidate even though
the initialization sequence is "otherwise ill-formed".
Pete Cooper [Mon, 26 Jan 2015 20:51:58 +0000 (20:51 +0000)]
Don't generate llvm.expect intrinsics with -O0.
The backend won't run LowerExpect on -O0. In a debug LTO build, this results in llvm.expect intrinsics being in the LTO IR which doesn't know how to optimize them.
Reid Kleckner [Mon, 26 Jan 2015 19:53:16 +0000 (19:53 +0000)]
Fix broken doc link to Clang 3.5 release notes
We appear to use 3.5.0 in the directory structure now. That's probably
unnecessary. We should probably let the micro releases update the docs
for the same minor version.
Ben Langmuir [Mon, 26 Jan 2015 19:04:10 +0000 (19:04 +0000)]
Fix assert instantiating string init of static variable
... when the variable's type is a typedef of a ConstantArrayType. Just
look through the typedef (and any other sugar). We only use the
constant array type here to get the element count.
Nico Weber [Mon, 26 Jan 2015 06:23:36 +0000 (06:23 +0000)]
Don't let virtual calls and dynamic casts call Sema::MarkVTableUsed().
clang currently calls MarkVTableUsed() for classes that get their virtual
methods called or that participate in a dynamic_cast. This is unnecessary,
since CodeGen only emits vtables when it generates constructor, destructor, and
vtt code. (*)
Note that Sema::MarkVTableUsed() doesn't cause the emission of a vtable.
Its main user-visible effect is that it instantiates virtual member functions
of template classes, to make sure that if codegen decides to write a vtable
all the entries in the vtable are defined.
While this shouldn't change the behavior of codegen (other than being faster),
it does make clang more permissive: virtual methods of templates (in particular
destructors) end up being instantiated less often. In particular, classes that
have members that are smart pointers to incomplete types will now get their
implicit virtual destructor instantiated less frequently. For example, this
used to not compile but does now compile:
template <typename T> struct OwnPtr {
~OwnPtr() { static_assert((sizeof(T) > 0), "TypeMustBeComplete"); }
};
class ScriptLoader;
struct Base { virtual ~Base(); };
struct Sub : public Base {
virtual void someFun() const {}
OwnPtr<ScriptLoader> m_loader;
};
void f(Sub *s) { s->someFun(); }
The more permissive behavior matches both gcc (where this is not often
observable, since in practice most things with virtual methods have a key
function, and Sema::DefineUsedVTables() skips vtables for classes with key
functions) and cl (which is my motivation for this change) – this fixes
PR20337. See this issue and the review thread for some discussions about
optimizations.
This is similar to r213109 in spirit. r225761 was a prerequisite for this
change.
Various tests relied on "a->f()" marking a's vtable as used (in the sema
sense), switch these to just construct a on the stack. This forces
instantiation of the implicit constructor, which will mark the vtable as used.
(*) The exception is -fapple-kext mode: In this mode, qualified calls to
virtual functions (`a->Base::f()`) still go through the vtable, and since the
vtable pointer off this doesn't point to Base's vtable, this needs to reference
Base's vtable directly. To keep this working, keep referencing the vtable for
virtual calls in apple kext mode.
Renato Golin [Sun, 25 Jan 2015 23:17:48 +0000 (23:17 +0000)]
Allows Clang to use LLVM's fixes-x18 option
This patch allows clang to have llvm reserve the x18
platform register on AArch64. FreeBSD will use this in the kernel for
per-cpu data but has no need to reserve this register in userland so
will need this flag to reserve it.
This uses llvm r226664 to allow this register to be reserved.
David Blaikie [Sun, 25 Jan 2015 07:44:05 +0000 (07:44 +0000)]
Fix the buildbots (fallout from r227028) by returning the exprloc of non-binary operator overload calls (and ->) to the start of the expression, not the location of the operator
I'll give this some further thought/discussion later, but this is enough
to unbreak the buildbots at least.
Nico Weber [Sun, 25 Jan 2015 02:04:36 +0000 (02:04 +0000)]
Rename four test files from .C to .cpp.
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.
David Blaikie [Sun, 25 Jan 2015 01:19:10 +0000 (01:19 +0000)]
DebugInfo: Use the preferred location rather than the start location for expression line info
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)