These don't actually require any registered backend to run.
This commit tests the water with a handful of fixes for what is a more
widespread problem.
llvm-svn: 212008
Add sign checks to deal with the fact that IR parser line/column pairs are
signed integers and sometimes invalid.
The crash path is potentially triggered by corrupt '.bc' files in practice,
though I don't have a binary input test case that can be checked-in right now.
(Unfortunately the backend itself crashes on various ill-formed '.bc' inputs so
this bandage isn't as helpful as it appears yet.)
llvm-svn: 212007
We'll want to share the implementation if anything else decides to check
for reserved names in future, so make this little snippet of code more
discoverable.
Also remove the __va_list_tag and __builtin_va_list special-case
checks. They're leftovers from before when the reserved name logic was
added.
No change in functionality.
llvm-svn: 212006
Windows on ARM defines va_list as a typedef for char *. Although the semantics
of argument passing for variadic functions matches AAPCS VFP, the wrapped
struct __va_list type is unused. This makes the intrinsic definition for
va_list match that of Visual Studio.
llvm-svn: 212004
It reverts commits as follows:
r211866: "Driver: use GNU::Link for the Generic_GCC toolchain"
r211895: "Replace GetProgramPath("ld") with GetLinkerPath()."
r211995: "Driver: add a cygwin linker tool"
llvm-svn: 211998
This adds a linker tool for the Windows cygwin environment. This linker
invocation is significantly different from the generic ld invocation. It
requires additional parameters as well as does not accept some normal
parameters. This should fix self-hosting on Cygwin.
llvm-svn: 211995
Some time ago, I noticed that try would get resolved incorrectly for Windows
Itanium targets. Add an explicit test to exsure that exceptions are handled
correctly for Windows Itanium environments.
llvm-svn: 211992
This corrects the handling for i686-windows-itanium. This environment is nearly
identical to Windows MSVC, except it uses the itanium ABI for C++.
llvm-svn: 211991
Summary: This patch introduces ACLE header file, implementing extensions that can be directly mapped to existing Clang intrinsics. It implements for both AArch32 and AArch64.
Reviewers: t.p.northover, compnerd, rengolin
Reviewed By: compnerd, rengolin
Subscribers: rnk, echristo, compnerd, aemerson, mroth, cfe-commits
Differential Revision: http://reviews.llvm.org/D4296
llvm-svn: 211962
This removes a const_cast added in r211884 that occurred due to an
inconsistency in how MemoryBuffers are handled between some parts of
clang and LLVM.
MemoryBuffers are immutable and the general convention in the LLVM
project is to omit const from immutable types as it's simply
redundant/verbose (see llvm::Type, for example). While this change
doesn't remove "const" from /every/ MemoryBuffer, it at least makes this
chain of ownership/usage consistent.
llvm-svn: 211915
This isn't 100% compatible with MSVC, but it's close enough. MSVC's /EH
flag doesn't really control exceptions so much as how to clean up after
an exception is thrown. The upshot is that cl.exe /EHs- will compile
try, throw, and catch statements with a warning, but clang-cl will
reject such constructs with a hard error. We can't compile such EH
constructs anyway, but this may matter to consumers of the AST.
Reviewers: hans
Differential Revision: http://reviews.llvm.org/D4317
llvm-svn: 211909
error handler is only registered once.
To avoid the use of std::call_once (the obvious way to do this) I've
wrapped everything up into a managed static and done the work in
a constructor. Silly, but it should be effective.
Some out-of-tree libclang users reported this to me, and I've asked them
to put together a test case which exhibits this behavior, but I wanted
to fix things ASAP since the nature of the fix is straight forward.
llvm-svn: 211905
selection re-enabled in r211900 in LLVM.
The approach (unlike r211121) doesn't rely on std::mutex or
std::call_once to avoid breaknig cygwin bots.
llvm-svn: 211901
This is a fix to the code in clang which inserts padding arguments to
ensure that the ARM backend can emit AAPCS-VFP compliant code. This code
needs to track the number of registers which have been allocated in order
to do this. When passing a very large struct (>64 bytes) by value, clang
emits IR which takes a pointer to the struct, but the backend converts this
back to passing the struct in registers and on the stack. The bug was that
this was being considered by clang to only use one register, meaning that
there were situations in which padding arguments were incorrectly emitted
by clang.
llvm-svn: 211898
The NEON intrinsics in arm_neon.h are designed to work on vectors
"as-if" loaded by (V)LDR. We load vectors "as-if" (V)LD1, so the
intrinsics are currently incorrect.
This patch adds big-endian versions of the intrinsics that does the
"obvious but dumb" thing of reversing all vector inputs and all
vector outputs. This will produce extra REVs, but we trust the
optimizer to remove them.
llvm-svn: 211893
Summary: This unbreaks our internal build after these tests were turned on in r211738.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: benlangmuir, cfe-commits
Differential Revision: http://reviews.llvm.org/D4311
llvm-svn: 211887
When we create a crashdump involving modules, we build a VFS to
reproduce the problem with. This updates the reproduction script to
use that VFS.
llvm-svn: 211876
This function is copying the entire file contents into memory repeatedly and
allocating new file IDs *each time* a source location is processed.
llvm-svn: 211874
This changes the behaviour of the driver for linking to match that of the
Generic_GCC::Assemble. The default link should use "ld" rather than "gcc" for
the linker as gcc does. This avoids the unnecessary round-tripping through gcc.
It also is much more reasonable behaviour from the user's perspective. This
should have been updated with SVN r195554 which changed the behaviour of
Generic_GCC::Assemble.
The gcc_forward test needs to be updated to mark the fact that -march is a flag
for GCC not ld. This was updated as a typo fix, but added a check for a flag
that is not a link flag.
The bindings test covers the change for testing, and thus no new test was added.
llvm-svn: 211866
At least this answers the question of whether .bc/.ll input processed by the
frontend produces identical output to the original compilation.
llvm-svn: 211853
Test that we can consume LLVM bitcode and additionally check that it produces
the same output as a direct compilation.
The feature is crashy and has gone untested until now, but we might as well
provide some coverage as long as it remains in tree.
Also test LL source input in the same way because the existing tests for that
don't look convincing.
llvm-svn: 211844
This silences false positives (leaks, use of uninitialized value) in simple
code that uses containers such as std::vector and std::list. The analyzer
cannot reason about the internal invariances of those data structures which
leads to false positives. Until we come up with a better solution to that
problem, let's just not inline the methods of the containers and allow objects
to escape whenever such methods are called.
This just extends an already existing flag "c++-container-inlining" and applies
the heuristic not only to constructors and destructors of the containers, but
to all of their methods.
We have a bunch of distinct user reports all related to this issue
(radar://16058651, radar://16580751, radar://16384286, radar://16795491
[PR19637]).
llvm-svn: 211832
Avoid a second key lookup when the back reference key is going to be
inserted in the StringMap. The string lookups in the msmangler are the
main responsible for the huge overhead when compared to the itanium
mangler. This patch makes a small but noticeable improvement.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4130
Patch by Agustín Bergé!
llvm-svn: 211813
when casting a retainable object to a objc_bridge_related
CF type with the suggestion of applying the method
specified in the bridging attribute to the object.
// rdar://15932435
llvm-svn: 211807
The Command will refer back to the Tool as its source,
so it has to outlive the Command.
Having the Tool on the stack would cause us to crash
when using "clang-cl -GR -fallback", because if the
Command fails, Driver::ExecuteCompilation tries to
peek at the Command's source.
Differential Revision: http://reviews.llvm.org/D4314
llvm-svn: 211802
Get the predefined macro for the architecture correct.
cortex-m4: __ARM_ARCH_7EM__
cortex-m3: __ARM_ARCH_7M__
cortex-m0: __ARM_ARCH_6M__
rdar://17420090
llvm-svn: 211792
This commit implements the -fuse-ld= option, so that the user
can specify -fuse-ld=bfd to use ld.bfd.
This commit re-applies r194328 with some test case changes.
It seems that r194328 was breaking macosx or mingw build
because clang can't find ld.bfd or ld.gold in the given sysroot.
We should use -B to specify the executable search path instead.
Patch originally by David Chisnall.
llvm-svn: 211785
Previously dllimport variables inside of template arguments relied on
not using the C++11 codepath when -fms-compatibility was set.
While this allowed us to achieve compatibility with MSVC, it did so at
the expense of MingW.
Instead, try to use the DeclRefExpr we dig out of the template argument.
If it has the dllimport attribute, accept it and skip the C++11
null-pointer check.
llvm-svn: 211766
Improve the warning when building with -fprofile-instr-use and a file
appears not to have been profiled at all. This keys on whether a
function is defined in the main file or not to avoid false negatives
when one includes a header with functions that have been profiled.
llvm-svn: 211760
Summary:
The BSDs and Darwin all forward the whole 'u' group, but gcc only
forwards -u so far as I can tell. I only forward -u, since that's a
minimal change, and many people object to magically recognizing and
forwarding linker arguments.
Reviewers: chandlerc, joerg
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4304
llvm-svn: 211756
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
For now, this is only used by its unit tests. It is similar to the API
in llvm::sys::fs::recursive_directory_iterator, but without some of the
more complex features like requesting that the iterator not recurse into
the next directory, for example.
llvm-svn: 211732
Consider the following code:
template <typename T> class Base {};
class __declspec(dllexport) class Derived : public Base<int> {}
When the base of an exported or imported class is a class template
specialization, MSVC will propagate the dll attribute to the base.
In the example code, Base<int> becomes a dllexported class.
This commit makes Clang do the proopagation when the base hasn't been
instantiated yet, and warns about it being unsupported otherwise.
This is different from MSVC, which allows changing a specialization
back and forth between dllimport and dllexport and seems to let the
last one win. Changing the dll attribute after instantiation would be
hard for us, and doesn't seem to come up in practice, so I think this
is a reasonable limitation to have.
MinGW doesn't do this kind of propagation.
Differential Revision: http://reviews.llvm.org/D4264
llvm-svn: 211725
With && at the top level of an expression, the last thing done when
emitting the expression was an unconditional jump to the cleanup block.
To reduce the amount of stepping, the DebugLoc is omitted from the
unconditional jump. This is done by clearing the IRBuilder's
"CurrentDebugLocation"*. If this is not set to some non-empty value
before the cleanup block is emitted, the cleanups don't get a location
either. If a call without a location is emitted in a function with debug
info, and that call is then inlined - bad things happen. (without a
location for the call site, the inliner would just leave the inlined
DebugLocs as they were - pointing to roots in the original function, not
inlined into the current function)
Follow up commit to LLVM will ensure that breaking the invariants of the
DebugLoc chains by having chains that don't lead to the current function
will fail assertions, so we shouldn't accidentally slip any of these
cases in anymore. Those assertions may reveal further cases that need to
be fixed in clang, though I've tried to test heavily to avoid that.
* See r128471, r128513 for the code that clears the
CurrentDebugLocation. Simply removing this code or moving the code
into IRBuilder to apply to all unconditional branches would regress
desired behavior, unfortunately.
llvm-svn: 211722
Types defined in function prototype are diagnosed earlier in C++ compilation.
They are put into declaration context where the prototype is introduced. Later on,
when FunctionDecl object is created, these types are moved into the function context.
This patch fixes PR19018 and PR18963.
Differential Revision: http://reviews.llvm.org/D4145
llvm-svn: 211718
Conditionally include x86intrin.h if we are building for x86 or x86_64.
Conditionalise definition of inline assembly routines which use x86 or x86_64
inline assembly. This is needed as clang can target Windows on ARM where these
definitions may be included into user code.
llvm-svn: 211716
[Clang part]
These patches rename the loop unrolling and loop vectorizer metadata
such that they have a common 'llvm.loop.' prefix. Metadata name
changes:
llvm.vectorizer.* => llvm.loop.vectorizer.*
llvm.loopunroll.* => llvm.loop.unroll.*
This was a suggestion from an earlier review
(http://reviews.llvm.org/D4090) which added the loop unrolling
metadata.
Patch by Mark Heffernan.
llvm-svn: 211712
The < 8 instead of <= 8 meant that a bunch of vreinterprets were not available on v8 AArch32. Simplify the guard to just !defined(aarch64) while we're at it, and enable some v8 AArch32 testing.
llvm-svn: 211686
The C++ language requires that the address of a function be the same
across all translation units. To make __declspec(dllimport) useful,
this means that a dllimported function must also obey this rule. MSVC
implements this by dynamically querying the import address table located
in the linked executable. This means that the address of such a
function in C++ is not constant (which violates other rules).
However, the C language has no notion of ODR nor does it permit dynamic
initialization whatsoever. This requires implementations to _not_
dynamically query the import address table and instead utilize a wrapper
function that will be synthesized by the linker which will eventually
query the import address table. The effect this has is, to say the
least, perplexing.
Consider the following C program:
__declspec(dllimport) void f(void);
typedef void (*fp)(void);
static const fp var = &f;
const fp fun() { return &f; }
int main() { return fun() == var; }
MSVC will statically initialize "var" with the address of the wrapper
function and "fun" returns the address of the actual imported function.
This means that "main" will return false!
Note that LLVM's optimizers are strong enough to figure out that "main"
should return true. However, this result is dependent on having
optimizations enabled!
N.B. This change also permits the usage of dllimport declarators inside
of template arguments; they are sufficiently constant for such a
purpose. Add tests to make sure we don't regress here.
llvm-svn: 211677
VarDecl provides a method getSourceRange(), which provides a more
robust way of getting the SourceRange since the TypeSourceInfo can
be null in certain cases.
Reviewed by: majnemer
Differential Revision: http://reviews.llvm.org/D4281
llvm-svn: 211667
Add predefined stdint macros that match the given patterns:
U?INT{_,_FAST,_LEAST}{8,16,32,64}_{MAX,TYPE}
U?INT{PTR,MAX}_{MAX,TYPE}
http://reviews.llvm.org/D4141
Author: binji
llvm-svn: 211657
Rather than having kw___if_exists be a special case of
ParseCompoundStatementBody, we can look for kw___if_exists in the big
switch over for valid statement tokens in ParseStatementOrDeclaration.
Nested __if_exists blocks are used in the DECLARE_REGISTRY_RESOURCEID
macro from atlcom.h.
llvm-svn: 211654
MSVC does not create a new scope for the body of an __if_exists compound
statement. Clang already gets this right today, but it was untested.
llvm-svn: 211650
When a user types:
int [4] foo;
assume that the user means:
int foo[4];
Update the information for 'foo' to prevent additional errors, and provide
a fix-it hint to move the brackets to the correct location.
Additionally, suggest parens for types that require it, such as:
int [4] *foo;
to:
int (*foo)[4];
llvm-svn: 211641
1) missing iterator bits needed by libstdc++4.7
Using find_if was convenient, but since operator++ wasn't a good
interface anyway, I just replaced with a range-based for loop and
removed operator++ from the directory_iterator class.
2) stop relying on order of iterating real files
llvm-svn: 211633
According to the x86-64 ABI, structures with both floating point and
integer members are split between floating-point and general purpose
registers, and consecutive 32-bit floats can be packed into a single
floating point register.
In the case of variadic functions these are stored to memory and the position
recorded in the va_list. This was already correctly implemented in
llvm.va_start.
The problem is that the code in clang for implementing va_arg was reading
floating point registers from the wrong location.
Patch by Thomas Jablin.
Fixes PR20018.
llvm-svn: 211626
The API is based on sys::fs::directory_iterator, but it allows iterating
over overlays and the yaml-based VFS. For now, it isn't used by
anything (except its tests).
llvm-svn: 211623
With LocTrackingOnly there's no longer a user-facing distinction so the NDEBUG
checks can go away. (Except maybe column info, but -verify only checks line
numbers anyway.)
Also add a RUN line to validate the traditional !LocTrackingOnly case.
llvm-svn: 211622
than one method with mismatched type of same selector name.
clang issues a warning to point this out since it may cause
undefined behavior. There are cases though that some APIs
don't care about user methods and such warnings are perceived as
noise. This patch allows users to add paren delimiters around
selector name to turn off such warnings. So, @selector((save:)) will
turn off the warning. It also provides 'fixit' so user knows
what to do. // rdar://16458579
llvm-svn: 211611
Summary:
This new debug emission kind supports emitting line location
information in all instructions, but stops code generation
from emitting debug info to the final output.
This mode is useful when the backend wants to track source
locations during code generation, but it does not want to
produce debug info. This is currently used by optimization
remarks (-Rpass, -Rpass-missed and -Rpass-analysis).
When one of the -Rpass flags is used, the front end will enable
location tracking, only if no other debug option is enabled.
To prevent debug information from being generated, a new debug
info kind LocTrackingOnly causes DIBuilder::createCompileUnit() to
not emit the llvm.dbg.cu annotation. This blocks final code generation
from generating debug info in the back end.
Depends on D4234.
Reviewers: echristo, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4235
llvm-svn: 211610
Summary:
The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or
is the default). It remains ld.so.1 for other cases.
This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008.
Differential Revision: http://reviews.llvm.org/D4273
llvm-svn: 211598
The address of dllimport functions can be accessed one of two ways:
- Through the IAT which is symbolically referred to with a symbol
starting with __imp_.
- Via the wrapper-function which ends up calling through the __imp_
symbol.
The problem with using the wrapper-function is that it's address will
not compare as equal in all translation units. Specifically, it will
compare unequally with the translation unit which defines the function.
This fixes PR19955.
llvm-svn: 211570
The address of dllimport variables isn't something that can be
meaningfully used in a constexpr context and isn't suitable for
evaluation at load-time. They require loads from memory to properly
evaluate.
This fixes PR19955.
Differential Revision: http://reviews.llvm.org/D4250
llvm-svn: 211568
Ensure that we properly handle the case where just the major version component
is provided by the user.
Thanks to Alp Toker for pointing out that this was not handled correctly!
llvm-svn: 211506
We were using old stat values for any files that had previously been
looked up, leading to badness. There might be a more elegant solution in
invalidating the cache for those file (since we already know which ones
they are), but it seems too likely there are existing references to
them hiding somewhere.
llvm-svn: 211504
clang_getCursorSpelling() doesn't assert on non-declarations any more and the
behaviour is covered by c-index tests.
Passes nosetests.
llvm-svn: 211482
This reverts commit r211467 which reverted r211408,r211410, it caused
crashes in test/SemaCXX/undefined-internal.cpp for i686-win32 targets.
llvm-svn: 211473
Custom diagnostics don't have a builtin class so this wouldn't have worked.
Reduces surface area of remark-related changes.
No test coverage.
llvm-svn: 211462
Make binaries built by MSVC, mingw and clang functionally equivalent. The
checks are trivially performed at runtime to eliminate functional differences
between supported configurations that used to be hard-coded.
llvm-svn: 211461
Don't try to find the MSVC version that the binaries were built with. Doing so
defeats testing by causing invalid test passes on the build servers.
Whichever Visual Studio (or clang-cl.exe) edition was used to build the clang
package, it's strictly orthogonal and has no relation to software versions
available on the user's PC.
llvm-svn: 211459
The purpose of bolding these is to make them visually distinct from
continuations (supplemental note diagnostics). Therefore, the bolding applies
to all severities _including_ remarks -- it's not in any way an indicator of
priority. Also simplify and comment.
No tests.
llvm-svn: 211447
This Lexer test unconditionally used the i128 integer literal suffix.
This suffix is only available to targets that have 128-bit arithmetic
support.
llvm-svn: 211446
Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.
Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211441
This reverts commit r211426.
This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux
llvm-svn: 211434
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.
This fixes PR20008.
Differential Revision: http://reviews.llvm.org/D4132
llvm-svn: 211426
The version information for Visual Studio is spread over multiple variables.
The newer Windows SDK has started making use of some of the extended versioning
variables that were previously undefined. Enhance our compatibility definitions
for these cases.
_MSC_VER is defined to be the Major * 100 + Minor. _MSC_FULL_VER is defined to
be Major * 10000000 + Minor * 100000 + Build. And _MSC_BUILD is the build
revision of the compiler.
Extend the -fmsc-version option in a compatible manner. If the value is the
previous form of MMmm, then we assume that the build number is 0. Otherwise, a
specific build number may be passed by using the form MMmmbbbbb. Due to
bitwidth limitations of the option, it is currently not possible to define a
revision value.
The version information can be passed as either the decimal encoded value
(_MSC_FULL_VER or _MSC_VER) or as a dot-delimited value.
The change to the TextDiagnostic is to deal with the updated encoding of the
version information.
llvm-svn: 211420
It's more flexible and arguably better layering to set flags to modify
compiling for diagnostics in the CC1 job themselves, rather than
tweaking the driver flags and letting them propagate.
There is one visible change this causes: crash report files will now
get preprocessed names (.i and friends).
llvm-svn: 211411
These tests relied on information that was only available for clang
builds that included asserts. Fix these tests to lift that restriction.
llvm-svn: 211408
This refactors the emission of dynamic_cast and typeid expressions so
that ABI specific knowledge lives in appropriate places. There are
quite a few benefits for having the two implementations share a common
core like sharing logic for optimization opportunities.
While we are at it, clean up the tests.
llvm-svn: 211402
When small arguments (structures < 8 bytes or "float") are passed in a
stack slot in the ppc64 SVR4 ABI, they must reside in the least
significant part of that slot. On BE, this means that an offset needs
to be added to the stack address of the parameter, but on LE, the least
significant part of the slot has the same address as the slot itself.
For the most part, this is handled in the LLVM back-end, where I just
fixed the LE case in commit r211368.
However, there is one piece of the clang front-end that is also aware of
these stack-slot offsets: PPC64_SVR4_ABIInfo::EmitVAArg. This patch
updates that routine to take endianness into account.
llvm-svn: 211370
FIXME: This fails on win32 due to ERROR_FILENAME_EXCED_RANGE if the working directory is too deep.
We should make Win32/Path.inc capable of long pathnames with '\\?\'.
llvm-svn: 211363
and is unrelated to the NEON intrinsics in arm_neon.h. On little
endian machines it works fine, however on big endian machines it
exhibits surprising behaviour:
uint32x2_t x = {42, 64};
return vget_lane_u32(x, 0); // Will return 64.
Because of this, explicitly call out that it is unsupported on big
endian machines.
This patch will emit the following warning in big-endian mode:
test.c:3:15: warning: vector initializers are a GNU extension and are not compatible with NEON intrinsics [-Wgnu]
int32x4_t x = {0, 1, 2, 3};
^
test.c:3:15: note: consider using vld1q_s32() to initialize a vector from memory, or vcombine_s32(vcreate_s32(), vcreate_s32()) to initialize from integer constants
1 warning generated.
llvm-svn: 211362
On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name
instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version).
This fixes the clang driver to pass the appropriate -dynamic-linker
setting, and adds some more tests to linux-ld.c.
llvm-svn: 211360
There was already partial support for multi-arch on powerpc64le,
but the MultiarchIncludeDirs setting was missing. This patch
adds the appropriate definition, and also extends the
linux-header-search.cpp test case to verify an Ubuntu 14.04
powerpc64le tree.
llvm-svn: 211359
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
Alexey Bataev