| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
request from Samuel F Antao).
llvm-svn: 212034
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4067
llvm-svn: 212010
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 212003
|
|
|
|
|
|
|
|
|
|
|
| |
Generic_GCC toolchain". It broke users of Generic_GCC, cygwin and mingw32.
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Remove unnecessary separation of anonymous namespace. NFC.
llvm-svn: 211990
|
|
|
|
|
|
|
| |
trigger on taking the address of a reference that is returned from a function
call.
llvm-svn: 211989
|
|
|
|
| |
llvm-svn: 211988
|
|
|
|
| |
llvm-svn: 211987
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 211984
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 211983
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 211982
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: rtrieu
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4325
llvm-svn: 211972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
The description had a misspelling. No functionality change.
llvm-svn: 211908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 211895
|
|
|
|
| |
llvm-svn: 211886
|
|
|
|
| |
llvm-svn: 211884
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Requires supporting changes from LLVM r211861.
llvm-svn: 211862
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 211806
|
|
|
|
| |
llvm-svn: 211805
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 211778
|
|
|
|
| |
llvm-svn: 211774
|
|
|
|
| |
llvm-svn: 211767
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 211764
|
|
|
|
|
|
| |
and count.
llvm-svn: 211763
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
By using vfs::recursive_directory_iterator, this warning will now fire
when some or all of a module's headers are from VFS mappings.
llvm-svn: 211746
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specialization bases (PR11170)
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conditional
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
|