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)
Larisse Voufo [Sat, 24 Jan 2015 23:09:54 +0000 (23:09 +0000)]
First steps in implementing DR1467: List-initialization of aggregate from same-type object.
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.
Richard Trieu [Sat, 24 Jan 2015 02:48:32 +0000 (02:48 +0000)]
When checking the template argument list, use a copy of that list for changes
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.
Richard Smith [Sat, 24 Jan 2015 01:07:20 +0000 (01:07 +0000)]
[modules] Sometimes we can deserialize a class member but not have yet
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).
Daniel Jasper [Fri, 23 Jan 2015 19:37:25 +0000 (19:37 +0000)]
clang-format: Fix another crasher caused by incomplete macro code.
We did't properly mark all of an AnnotatedLine's children as finalized
and thus would reformat the same tokens in different branches of #if/#else
sequences leading to invalid replacements.
Sanjay Patel [Fri, 23 Jan 2015 16:40:50 +0000 (16:40 +0000)]
Process the -fno-signed-zeros optimization flag (PR20870)
The driver currently accepts but ignores the -fno-signed-zeros flag.
This patch passes the flag through and enables 'nsz' fast-math-flag
generation in IR.
The existing OpenCL flag for the same functionality is made into an
alias here. It may be removed in a subsequent patch.
This should resolve bug 20870 ( http://llvm.org/bugs/show_bug.cgi?id=20870 );
patches for the optimizer were checked in at:
http://llvm.org/viewvc/llvm-project?view=revision&revision=225050
http://llvm.org/viewvc/llvm-project?view=revision&revision=224583
Rafael Espindola [Fri, 23 Jan 2015 05:26:38 +0000 (05:26 +0000)]
[pr22293] Don't crash during codegen of a recursive destructor.
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.
Richard Smith [Fri, 23 Jan 2015 00:01:13 +0000 (00:01 +0000)]
PR22299: Relocate code for handling -fmodule-map-file= so that we don't try to
produce diagnostics with source locations before the diagnostics system is
ready for them.
Richard Smith [Thu, 22 Jan 2015 23:07:47 +0000 (23:07 +0000)]
Reorganize test/Modules:
* 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.
Alexey Bataev [Thu, 22 Jan 2015 06:17:56 +0000 (06:17 +0000)]
[OPENMP] CodeGen for "omp atomic read [seq_cst]" directive.
"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
projects / clang / log