When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probably
based on the assumptions:
* The location of the compound statement should be the member's location
* The compound statement if present is the last element of a FunctionDecl
This patch changes the location of the compound statement to the
member's end location.
Code review: http://reviews.llvm.org/D4175
llvm-svn: 211344
This reimplements part of r211303 in a bit of a cleaner way. Doing so
allows us to use a proper absolute path when calling addFileMapping
rather than relying on a substring being one, which should fix the
tests on Windows.
llvm-svn: 211338
Successfully loaded module files may be referenced in other
ModuleManagers, so don't invalidate them. Two related things are fixed:
1) I thought the last module in the manager was always the one that
failed, but it isn't. So check explicitly against the list of
vetted modules from ReadASTCore.
2) We now keep the file descriptor of pcm file open, which avoids the
possibility of having two different pcms for the same module loaded when
building in parallel with headers being modified during a build.
<rdar://problem/16835846>
llvm-svn: 211330
a qualified-id type because pointer is object of a forward
class declaration, include this info in a diagnostic note.
// rdar://10751015
llvm-svn: 211324
This adds the -module-dependency-dir to clang -cc1, which specifies a
directory to copy all of a module's dependencies into in a form
suitable to be used as a VFS using -ivfsoverlay with the generated
vfs.yaml.
This is useful for crashdumps that involve modules, so that the module
dependencies will be intact when a crash report script is used to
reproduce a problem on another machine.
We currently encode the absolute path to the dump directory, due to
limitations in the VFS system. Until we can handle relative paths in
the VFS, users of the VFS map may need to run a simple search and
replace in the file.
llvm-svn: 211303
This patch fixes a crash when handling malformed arguments to loop pragmas such
as: "#pragma clang loop vectorize(()". Essentially any argument which is not an
identifier or constant resulted in a crash. This patch also changes a couple of
the error messages which weren't quite correct. New behavior with this patch vs
old behavior:
#pragma clang loop vectorize(1)
OLD: error: missing keyword; expected 'enable' or 'disable'
NEW: error: invalid argument; expected 'enable' or 'disable'
#pragma clang loop vectorize()
OLD: error: expected ')'
NEW: error: missing argument to loop pragma 'vectorize'
#pragma clang loop vectorize_width(bad)
OLD: error: missing value; expected a positive integer value
NEW: error: invalid argument; expected a positive integer value
#pragma clang loop vectorize(bad)
OLD: invalid keyword 'bad'; expected 'enable' or 'disable'
NEW: error: invalid argument; expected 'enable' or 'disable'
http://reviews.llvm.org/D4197
Patch by Mark Heffernan
llvm-svn: 211292
Extend the documentation for "#pragma clang loop" hints to include the unroll
and unroll_count directives.
Patch by Mark Heffernan [http://reviews.llvm.org/D4198]
llvm-svn: 211286
Make it return void and delete the dead code in the parser that handled
the case where it might return false. This has been dead since 2010
when John deleted Action.h.
llvm-svn: 211248
retainable ObjC pointers without requiring a bridge-cast
in the context of pointer comparison as this is in effect
a +0 context. // rdar://16627903
llvm-svn: 211243
CL permits static redeclarations to follow extern declarations. The
storage specifier on the latter declaration has no effect.
This fixes PR20034.
Differential Revision: http://reviews.llvm.org/D4149
llvm-svn: 211238
Relax the tests to allow for differences between release and debug builds. This
should fix the buildbots.
Thanks to Benjamin Kramer and Eric Christo for their invaluable tip that this
was release build specific issue.
llvm-svn: 211227
Add support for _InterlockedCompareExchangePointer, _InterlockExchangePointer,
_InterlockExchange. These are available as a compiler intrinsic on ARM and x86.
These are used directly by the Windows SDK headers without use of the intrin
header.
llvm-svn: 211216
Doing this caused us to mistakenly think we'd seen a particular state before
when we actually hadn't, which resulted in false negatives. Credit to
Rafael Auler for discovering this issue!
llvm-svn: 211209
In the final phase of the merge, I managed to disable a bunch of Clang
tests accidentally. Fortunately none of them seem to have broken in
the interim.
llvm-svn: 211149
When instantiating dllimport variables with dynamic initializers, don't
bail out of Sema::InstantiateVariableInitializer without calling
PopExpressionEvaluationContext().
This was causing a stale object to stay on the ExprEvalContexts stack,
causing subsequent calls to getCurrentMangleNumberContext() to fail,
resulting in incorrect numbering of static locals (and probably other
broken things).
llvm-svn: 211137
That's what I get for hurredly splitting the small change out of a much
bigger change that had moved where checkCorrectionVisibility was being
called.
llvm-svn: 211134
IBOutlet and weak attributes when accessed being
unpredictably set to nil because usage of such properties
are always single threaded and its ivar cannot be set
to nil asynchronously. // rdar://15885642
llvm-svn: 211132
When another clang instance builds a module, it may still be considered
"out of date" for the current instance in a couple of cases*. This
patch prevents us from giving spurious errors when compilers race to
build a module by allowing the module load to fail when the pcm was
built by a different compiler instance.
* Cases where a module can be out of date despite just having been
built:
1) There are different -I paths between invocations that result in
finding a different module map file for some dependent module. This is
not an error, and should never be diagnosed.
<rdar://problem/16843887>
2) There are file system races where the headers making up a module are
touched or moved. Although this can sometimes mean trouble, diagnosing
it only during a build-race is worse than useless and we cannot detect
this in general. It is more robust to just rebuild. This was causing
spurious issues in some setups where only the modtime of headers was
bumped during a build.
<rdar://problem/16157638>
llvm-svn: 211129
The parsing for -Rpass= had been factored into the function
GenerateOptimizationRemarkRegex, but at the time I forgot to remove
the original code that just handled OPT_Rpass_EQ.
llvm-svn: 211122
This reverts commit r211096. Looks like it broke the msvc build:
SemaOpenMP.cpp(140) : error C4519: default template arguments are only allowed on a class template
llvm-svn: 211113
There comes a time in the life of any amateur code generator when dumb string
concatenation just won't cut it any more. For NeonEmitter.cpp, that time has
come.
There were a bunch of magic type codes which meant different things depending on
the context. There were a bunch of special cases that really had no reason to be
there but the whole thing was so creaky that removing them would cause something
weird to fall over. There was a 1000 line switch statement for code generation
involving string concatenation, which actually did lexical scoping to an extent
(!!) with a bunch of semi-repeated cases.
I tried to refactor this three times in three different ways without
success. The only way forward was to rewrite the entire thing. Luckily the
testing coverage on this stuff is absolutely massive, both with regression tests
and the "emperor" random test case generator.
The main change is that previously, in arm_neon.td a bunch of "Operation"s were
defined with special names. NeonEmitter.cpp knew about these Operations and
would emit code based on a huge switch. Actually this doesn't make much sense -
the type information was held as strings, so type checking was impossible. Also
TableGen's DAG type actually suits this sort of code generation very well
(surprising that...)
So now every operation is defined in terms of TableGen DAGs. There are a bunch
of operators to use, including "op" (a generic unary or binary operator), "call"
(to call other intrinsics) and "shuffle" (take a guess...). One of the main
advantages of this apart from making it more obvious what is going on, is that
we have proper type inference. This has two obvious advantages:
1) TableGen can error on bad intrinsic definitions easier, instead of just
generating wrong code.
2) Calls to other intrinsics are typechecked too. So
we no longer need to work out whether the thing we call needs to be the Q-lane
version or the D-lane version - TableGen knows that itself!
Here's an example: before:
case OpAbdl: {
std::string abd = MangleName("vabd", typestr, ClassS) + "(__a, __b)";
if (typestr[0] != 'U') {
// vabd results are always unsigned and must be zero-extended.
std::string utype = "U" + typestr.str();
s += "(" + TypeString(proto[0], typestr) + ")";
abd = "(" + TypeString('d', utype) + ")" + abd;
s += Extend(utype, abd) + ";";
} else {
s += Extend(typestr, abd) + ";";
}
break;
}
after:
def OP_ABDL : Op<(cast "R", (call "vmovl", (cast $p0, "U",
(call "vabd", $p0, $p1))))>;
As an example of what happens if you do something wrong now, here's what happens
if you make $p0 unsigned before the call to "vabd" - that is, $p0 -> (cast "U",
$p0):
arm_neon.td:574:1: error: No compatible intrinsic found - looking up intrinsic 'vabd(uint8x8_t, int8x8_t)'
Available overloads:
- float64x2_t vabdq_v(float64x2_t, float64x2_t)
- float64x1_t vabd_v(float64x1_t, float64x1_t)
- float64_t vabdd_f64(float64_t, float64_t)
- float32_t vabds_f32(float32_t, float32_t)
... snip ...
This makes it seriously easy to work out what you've done wrong in fairly nasty
intrinsics.
As part of this I've massively beefed up the documentation in arm_neon.td too.
Things still to do / on the radar:
- Testcase generation. This was implemented in the previous version and not in
the new one, because
- Autogenerated tests are not being run. The testcase in test/ differs from
the autogenerated version.
- There were a whole slew of special cases in the testcase generation that just
felt (and looked) like hacks.
If someone really feels strongly about this, I can try and reimplement it too.
- Big endian. That's coming soon and should be a very small diff on top of this one.
llvm-svn: 211101
We may not have the mangling for static locals vs. enums completely figured out,
but at least for my simple test cases, enums should not increment the mangling
number.
Differential Revision: http://reviews.llvm.org/D4164
llvm-svn: 211078
Otherwise, it could allows local users to obtain sensitive information or
overwrite arbitrary files via a symlink attack on temporary directories with
predictable names.
Reported as CVE-2014-2893 ( https://security-tracker.debian.org/tracker/CVE-2014-2893 )
Found by Jakub Wilk
llvm-svn: 211051
Summary:
The RTTI scheme for x86_64 is largely the same as the one for i386.
Differences are largely limited to avoiding load-time relocations by
replacing pointers to RTTI metadata with the difference of that data
relative to the load address of the module.
Interestingly, this precludes the possibility of successfully using RTTI
data from another DLL. The ImageBase reference is always relative to
the current DLL.
Differential Revision: http://reviews.llvm.org/D4148
llvm-svn: 211041
By describing system header suppressions directly in tablegen we eliminate
special cases in getDiagnosticSeverity().
Dropping the reliance on builtin diagnostic classes when mapping also gets us
closer to the goal of reusing the diagnostic machinery for custom diagnostics.
No change in functionality.
llvm-svn: 211023
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
llvm-svn: 211005
This improves conformance with ACLE 6.4.1. Define additional macros that
indicate support for the ARM and Thumb instruction set architecture. This
includes the following set of macros:
__ARM_ARCH
__ARM_ARCH_ISA_ARM
__ARM_ARCH_ISA_THUMB
__ARM_32BIT_STATE
These help identify the environment that the code is intended to execute on.
Adjust the handling for ACLE 6.4.2 to be more correct. We would define the
profile as a free-standing token rather than a quoted single character.
llvm-svn: 210991
instead of report-XXXXXX.html, scan-build/clang analyzer generate
report-<filename>-<function, method name>-<function position>-<id>.html.
(id = i++ for several issues found in the same function/method)
llvm-svn: 210970
Fixes a crash in Retain Count checker error reporting logic by handing
the allocation statement retrieval from a BlockEdge program point.
Also added a simple CFG dump routine for debugging.
llvm-svn: 210960
Most builtins date from before the "cmpxchg weak" was a gleam in the
C++ committee's eye, so fortunately not much needs to change. But a
few of them *do* acknowledge that failure is possible.
For these, we'll emit the usual cartesian product of cmpxchg
operations if we can't statically determine weakness. CodeGen can
sort it out later if the function gets inlined.
The only other non-trivial aspect of this is (I think) that we emit
the scalar expression for "IsWeak" once, at the beginning, and
propagate its value through the successive blocks. There's not much in
it, but it's slightly more consistent with the existing handling of
FailureOrder.
llvm-svn: 210932
There are several Altivec tests that formerly ran only on big-endian
targets (and in some cases only on 32-bit targets). It is useful to
verify these on little-endian targets as well.
While testing these, I discovered a typo in <altivec.h>. This is also
fixed by this patch.
llvm-svn: 210928
hint attributes. Includes tests for pragma printing and for attribute order
which is incorrectly reversed by ParsedAttributes.
Reviewed by Aaron Ballman
llvm-svn: 210925
Init-order and use-after-return modes can currently be enabled
by runtime flags. use-after-scope mode is not really working at the
moment.
The only problem I see is that users won't be able to disable extra
instrumentation for init-order and use-after-scope by a top-level Clang flag.
But this instrumentation was implicitly enabled for quite a while and
we didn't hear from users hurt by it.
llvm-svn: 210924
This is a minimal fix for clang. I'll soon add support for generating
weak variants when requested, but that's not really necessary for the
LLVM change in isolation.
llvm-svn: 210907
Summary:
Do not store duplicate parents when memoization data is available.
This does not solve the duplication problem, but ameliorates it.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D4124
llvm-svn: 210902
CRTP-like patterns involve a class which inherits from another class
using itself as a template parameter.
However, the base class itself may try to create a pointer-to-member
which involves the derived class. This is problematic because we
may not have finished parsing the most derived classes' base specifiers
yet.
It turns out that MSVC simply uses the unspecified inheritance model
instead of doing anything fancy.
This fixes PR19987.
llvm-svn: 210886
Summary:
'sizeof' is a UnaryExprOrTypeTrait, and it can contain either a type or
an expression. This change threads a RecoveryTSI parameter through the
layers between TransformUnaryExprOrTypeTrait the point at which we look
up the type. If lookup finds a single type result after instantiation,
we now build TypeSourceInfo for it just like a normal transformation
would.
This fixes the last error in the hello world ATL app that I've been
working with, and it now links and runs with clang. Please try it and
file bugs!
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4108
llvm-svn: 210855
Previously we would do the access check from the context of
MarkVTableUsed.
Also update this test to C++11, since that is typically used with the MS
C++ ABI.
Fixes PR20005.
llvm-svn: 210850
1. Having "get started", "get involved", and "hacking" makes it hard to find
how to send patches, so add a link from "get involved" to "hacking".
2. Remove an almost 5 year old note on the test running meachanism changing
soon.
3. Let "hacking" link to the LLVM developer policy.
llvm-svn: 210826
to call themselves will get the warning:
"Capturing <itself> strongly in this block is likely to
lead to a retain cycle". Cut down on the amount of noise
by noticing that user at some point sets the captured variable
to null in order to release it (and break the cycle).
// rdar://16944538
llvm-svn: 210823
Previously we would calculate the inheritance model of a class when
requiring a pointer to member type of that class to be complete. The
inheritance model is used to figure out how many fields are used by the
member pointer.
However, once we require a pointer to member of a derived class type to
be complete, we can form pointers to members of bases without
calculating the inheritance model for those bases. This was causing
crashes on this simple test case:
struct A {
void f();
void f(int);
};
struct B : public A {};
void g() { void (B::*a)() = &B::f; }
Now we calculate the inheritance models of all base classes when
completing a member pointer type.
Fixes PR2007.
llvm-svn: 210813
Thanks to David Blakie and Richard Smith for pointing out that we can retain the
-Wswitch coverage while avoiding the warning from GCC by pushing the unreachable
outside of the switch!
llvm-svn: 210812
tools/clang/lib/Basic/DiagnosticIDs.cpp: In function ‘clang::DiagnosticIDs::Level toLevel(clang::diag::Severity)’:
tools/clang/lib/Basic/DiagnosticIDs.cpp:382:1: warning: control reaches end of non-void function [-Wreturn-type]
tools/clang/lib/Format/Format.cpp: In member function ‘virtual std::string clang::format::ParseErrorCategory::message(int) const’:
tools/clang/lib/Format/Format.cpp:282:1: warning: control reaches end of non-void function [-Wreturn-type]
Add a default cases that asserts that we handle the severity, parse error.
llvm-svn: 210804
This begins to address cognitive dissonance caused by treating the Note
diagnostic level as a severity in the diagnostic engine.
No change in functionality.
llvm-svn: 210758
Current MSVC versions don't have move assignment operators, so we
can't rely on them being available in the dll. If we have the
definition, we can just use that directly. This breaks pointer
equality, but should work fine otherwise.
When there is an MSVC version that supports move assignment,
we can key this off the -fmsc-ver option.
http://reviews.llvm.org/D4105
llvm-svn: 210715
Also move the constructor for NamespaceSpecifierSet out of line to
improve the class' readability. I meant to do these two things while
cleaning up the previous TypoCorrectionConsumer changes and have them
folded into those changes.
No functionality changed.
llvm-svn: 210686
SpecifierInfo is not used outside of NamespaceSpecifierSet except
indirectly through NamespaceSpecifierSet's iterator, so clean up the
code a bit by moving SpecifierInfo into NamespaceSpecifierSet. Also drop
SpecifierInfo's trivial yet verbose constructor since brace
initiialization is sufficient in the only two places the constructor was
being explicitly called.
No functionality changed.
llvm-svn: 210672
The SpecifierInfo and NamespaceSpecifierSet are now only used by
TypoCorrectionConsumer, so treat them as the implementation details of
TypoCorrectionConsumer that they are. Also make NamespaceSpecifierSet's
method names more style guide compliant.
No functionality changed.
llvm-svn: 210671
The only external/visible functional change that fell out of this
refactoring is that there was one less case where the typo caching
and/or counting didn't work properly. The result is that a test case
had to be moved from typo-correction.cpp to typo-correction-pt2.cpp
to avoid the hard-coded limit on per file/TU typo correction attempts.
llvm-svn: 210669
This is in preparation for moving TypoCorrection filtering
into the TypoCorrectionConsumer, to separate out some of the purely
mechanical churn. It also makes some of the method names in
NamespaceSpecifierSet be more style guide compliant.
No functionality changed.
llvm-svn: 210668
correctly when both NSAttributedString and
NSMutableAttributedString are specified on the same
CFStruct via different typedefs. // rdar://17238954
llvm-svn: 210660
The vec_sld and vec_vsldoi interfaces perform a left-shift on vector
arguments for both big and little endian. However, because they rely
on the vec_perm interface which is endian-dependent, the permutation
vector needs to be reversed for LE to get the proper shift direction.
I've added some extra testing for these interfaces for LE in the
builtins-ppc-altivec.c.
llvm-svn: 210657
r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it
did not believe that there is a distinction between class templates and
function templates.
Sadly, there is. Function templates should behave in a compatible
manner with MSVC.
llvm-svn: 210642
Summary:
Previously, we would mangle nullptr pointer-to-member-functions in class
templates with a mangling we invented because contemporary versions of
MSVC would crash when trying to compile such code.
However, VS "14" can successfully compile these sorts of template
instantiations. This commit updates our mangling to be compatible with
theirs.
Reviewers: rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4059
llvm-svn: 210637
The backing store of thread local variables is internal for OS X and all
accesses must go through the thread wrapper.
However, individual TUs may have inlined through the thread wrapper.
To fix this, give the thread wrapper functions WeakAnyLinkage. This
prevents them from getting inlined into call-sites.
This fixes PR19989.
llvm-svn: 210632
For ARM target, we can use CRYPTO and CRC features if we select
cortex-a57 by '-mcpu', but for AArch64 target, it doesn't work
unless adding with '-mfpu=crypto-neon-fp-armv8'. To keep consistency
between front-end and back-end and get end-users more easier to use,
we'd better add default feature for CPUs on AArch64 target as well.
llvm-svn: 210625
We currently allow unqualified lookup for instance methods but not
static methods because we can't recover with a semantic 'this->'
insertion.
ATL headers have static methods that do unqualified lookup into
dependent base classes. The pattern looks like:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Bar; }
};
Now we recover as if the user had written:
template <typename T> struct Foo : T {
static int *getBarFromT() { return Foo::Bar; }
};
... which will eventually look up Bar in T at instantiation time.
Now we emit a diagnostic in both cases, and delay lookup in other
contexts where 'this' is available and refers to a class with dependent
bases.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4079
llvm-svn: 210611
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.
llvm-svn: 210608
While matching a non-type template argument against a known template
type parameter we now modify the AST's TemplateArgumentLoc to assume the
user wrote typename. Under -fms-compatibility, we downgrade our
diagnostic from an error to an extwarn.
Reviewed by: rsmith
Differential Revision: http://reviews.llvm.org/D4049
llvm-svn: 210607
The changes in r204978 broke win32-macho targets. There were checks added for
MSVC and Itanium environments as special cases, and win32-macho needs to be
treated the same way.
llvm-svn: 210584
We would previously end up with an error when instantiating the
following template:
template <typename> struct __declspec(dllimport) S {
void foo() = delete;
};
S<int> s;
error: attribute 'dllimport' cannot be applied to a deleted function
llvm-svn: 210550
Clang's lit cfg already detects the currently selected SDK via
"xcrun --show-sdk-path". The same thing should be done for compiler-rt tests,
to make them work on recent OS X versions. Instead of duplicating the detection
code, this patch extracts the detection function into a lit.util method.
Patch by Kuba Brecka (kuba.brecka@gmail.com),
reviewed at http://reviews.llvm.org/D4072
llvm-svn: 210534
Diagnostic mappings are used to calculate the final severity of diagnostic
instances.
Detangle the implementation to reflect the terminology used in documentation
and bindings.
No change in functionality.
llvm-svn: 210518
Doing so would be inconsistent with the common fallback case where backend
diagnostics without source locations are emitted unconditionally.
llvm-svn: 210515
Anyone enabling this warning would expect to hear about all occurrences
including those in system headers that can cause non-reproducible builds.
To achieve this, rework ShowInSystemHeader to remove broken unused mapping code
that didn't make sense with a simpler and correct scheme.
llvm-svn: 210512
We would previously assert if the initializer was dependent. I also think that
checking isConstantInitializer is more correct here than checkInitIsICE.
llvm-svn: 210505
It turns out the trailing '=' really is part of the option name spelling and
treating it as such gets us compatible with GCC's -Werror= and pragmas.
(GCC doesn't appear to support any -Wno- form for this diagnostic but we do.)
llvm-svn: 210503
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
llvm-svn: 210498
Eli Bendersky