In retrospect, it seems "obvious" that the sense of the return code is
the same as if it crashed on "interesting" inputs. But that didn't stop
me from spending more time than I care to admit verifying this.
llvm-svn: 264119
ISL can conclude additional conditions on parameters from restrictions
on loop variables. Such conditions persist when leaving the loop and the
loop variable is projected out. This results in a narrower domain for
exiting the loop than entering it and is logically impossible for
non-infinite loops.
We fix this by not adding a lower bound i>=0 when constructing BB
domains, but defer it to when also the upper bound it computed, which
was done redundantly even before this patch.
This reduces the number of LNT fails with -polly-process-unprofitable
-polly-position=before-vectorizer from 8 to 6.
llvm-svn: 264118
Turns out that checking only x86 for empty atoms to fix UBSan then
requires the same code in the other targets too. Better to just
check this in the main run loop instead of in each target.
Should be NFC, other than fixing UBSan failures.
llvm-svn: 264116
This was caught by the UBSan bot. When the atom has no size, we would
issue a memcpy with size0 and a nullptr for the source.
Also, this code should never have references inside an empty atom so
add an assert for that while we're here.
llvm-svn: 264115
FileSystem::Fopen is a lldb_private API, but lldb-mi uses only the
public API. Depending on lldb_private APIs makes Xcode builds fail.
I reverted the portion of r264074 that added such a dependency.
llvm-svn: 264113
Ensure we keep the symbol we need to before it reaches
the Writer (and hit an assertion), changing its linkage
from linkonce_odr to weak. For a more detailed description
of the problem, see PR19901 where a similar problem was
fixed for the gold plugin. Thanks to Rafael for providing
a testcase.
llvm-svn: 264111
MCContext shouldn't be accessing the filesystem - that's a gross
layering violation and makes it awkward to use as a library or in a
daemon where it may not even be allowed filesystem access.
The CWD lookup here is normally redundant anyway, since the calling
context either also looks up the CWD or sets this to something more
specific. Here, we fix up the one caller that doesn't already set up a
debug compilation dir and make it clear that the responsibility for
such set up is in the users of MCContext.
llvm-svn: 264109
Summary:
I've completed my audit of all the code that looks at noduplicate and
added handling of convergent where appropriate, so we no longer need
noduplicate on these intrinsics.
Reviewers: jholewinski
Subscribers: llvm-commits, jholewinski
Differential Revision: http://reviews.llvm.org/D18168
llvm-svn: 264107
We bail out if current scop has a complex control flow as this could lead to
building of large domain conditions. This is to reduce compile time. This
addresses r26382.
Contributed-by: Chris Jenneisch <chrisj@codeaurora.org>
Differential Revision: http://reviews.llvm.org/D18362
llvm-svn: 264105
A really unfortunate design of llvm-link and related libraries is that
they operate one module at a time.
This means they can copy a GV to the destination module that should not
be there in the final result because a later bitcode file takes
precedence.
We already handled cases like a strong GV replacing a weak for example.
One case that is not currently handled is a comdat replacing another.
This doesn't happen in ELF, but with COFF largest selection kind it is
possible.
In "llvm-link a.ll b.ll" if the selected comdat was from a.ll,
everything will work and we will not copy the comdat from b.ll.
But if we run "llvm-link b.ll a.ll", we fail to delete the already
copied comdat from b.ll. This patch fixes that.
llvm-svn: 264103
CGP modifies the domtree in some cases, so saying that it preserves the
domtree is a lie. We'll be able to selectively preserve it with the new
pass manager.
Differential Revision: http://reviews.llvm.org/D16893
llvm-svn: 264099
If the LHS of 'a = b' already had an atom in it then we wouldn't
call the destructor. This happens when we use something like
std::remove_if which is done in the CompactUnwindPass. Should fix
the leaks on the mach-o/unwind-info-simple-x86_64.yaml test case.
Lang and I are going to take a look at removing OwningAtomPtr in
favour of a std::unique_ptr but just trying to get the bots green
so we have a good baseline first.
llvm-svn: 264097
This patch adds a new ExecutionPolicy, eExecutionPolicyTopLevel, which
tells the expression parser that the expression should be JITted as top
level code but nothing (except static initializers) should be run. I
have modified the Clang expression parser to recognize this execution
policy. On top of the existing patches that support storing IR and
maintaining a map of arbitrary Decls, this is mainly just patching up a
few places in the expression parser.
I intend to submit a patch for review that exposes this functionality
through the "expression" command and through the SB API. That patch
also includes a testcase for all of this.
<rdar://problem/22864976>
llvm-svn: 264095
The code for LTO has been growing, so now is probably a good time to
move it to its own file. SymbolTable.cpp is for symbol table, and
because compiling bitcode files are semantically not a part of
symbol table, this is I think a good thing to do.
http://reviews.llvm.org/D18370
llvm-svn: 264091
We were just completely ignoring the types when determining whether we could
safely emit a libcall as a tail call. This is clearly wrong.
Theoretically, we could dig deeper looking for incidental matches (much like
the generic code in Analysis.cpp does), but it's probably not worth it for the
few libcalls that exist.
llvm-svn: 264084
When you have multiple LCSSA (single-operand) PHIs that are converted
into two-operand PHIs due to versioning, only assert that the PHI
currently being converted has a single operand. I.e. we don't want to
check PHIs that were converted earlier in the loop.
Fixes PR27023.
Thanks to Karl-Johan Karlsson for the minimized testcase!
llvm-svn: 264081
Summary:
There is a silly bug that got introduced after fixing incorrect paths with this patch:
http://reviews.llvm.org/D18293
The tests was present twice in the file.
Reviewers: alexfh, rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18365
llvm-svn: 264080
OwningAtomPtr does not have OwningAtomPtr(OwningAtomPtr&) or the equivalent
operator= as we only want to use rvalue references in it.
SortKey didn't like this on MSVC as it was synthesizing SortKey(SortKey&) and
trying to use the OwningAtomPtr(OwningAtomPtr&) method which was private an
unimplemented.
Now we explicitly have the methods on SortKey so hopefully the bot will be
happier.
llvm-svn: 264077
Summary:
The string constructors are not defined using optional parameters and are not recognize by the checker.
The constructor defined in the MSVC header is defined with 1 parameter. Therefore, patterns are not recognized by the checker.
The current patch add support to accept constructor with only one parameter.
Repro on a Visual Studio 14 installation with the following code:
```
void f1(const std::string &s) {
f1(s.c_str());
}
```
In the xstring.h header, the constructors are defined this way:
```
basic_string(const _Myt& _Right) [...]
basic_string(const _Myt& _Right, const _Alloc& _Al) [...]
```
The CXXConstructExpr to recognize only contains 1 parameter.
```
CXXConstructExpr 0x3f1a070 <C:\src\llvm\examples\test.cc:6:6, col:14> 'const std::string':'const class std::basic_string<char, struct std::char_traits<char>, class
std::allocator<char> >' 'void (const char *) __attribute__((thiscall))'
`-CXXMemberCallExpr 0x3f1a008 <col:6, col:14> 'const char *'
`-MemberExpr 0x3f19fe0 <col:6, col:8> '<bound member function type>' .c_str 0x3cc22f8
`-DeclRefExpr 0x3f19fc8 <col:6> 'const std::string':'const class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char> >' lvalue ParmVar 0x3f19c80 's' 'const std::string &'
```
Reviewers: aaron.ballman, alexfh
Subscribers: aemerson
Differential Revision: http://reviews.llvm.org/D18285
llvm-svn: 264075
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
Summary:
Invalid source location are causing clang-tidy to crash when manipulating an invalid file.
Macro definitions on the command line have locations in a virtual buffer and therefore
don't have a corresponding valid FilePath.
A recent patch added path conversion to absolute path. As the FilePath may now be empty,
the result of makeAbsolutePath may incorrectly be the folder WorkingDir. The crash occurs
in getLocation which is not able to find the appropriate FileEntry (null pointer).
```
SmallString<128> FixAbsoluteFilePath = Fix.getFilePath();
Files.makeAbsolutePath(FixAbsoluteFilePath);
FixLoc = getLocation(FixAbsoluteFilePath, Fix.getOffset());
```
With relative path, the code was not crashing because getLocation was skipping empty path.
Example of code:
```
int main() { return X; }
```
With the given command-line:
```
clang-tidy test.cc --checks=misc-macro-* -- -DX=0+0
```
Reviewers: alexfh, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D18262
llvm-svn: 264073
The range here isn't over references, so using `auto &` here incites a
copy. Switching to `auto *` would do, but we might as well list an
explicit type for clarity.
Found by -Wrange-loop-analysis.
llvm-svn: 264071
The AtomVector class is an internal detail of File so I moved it
to be protected in r264067. However, the MSVC bots don't like the
global declarations of type File::AtomVector in File.cpp so it needs
to go back to being public for now.
llvm-svn: 264070
Summary:
The string constructors are not defined using optional parameters and are not recognized by the redundant-string-init checker.
The following patch fixes the redundant-string-init checker for the Visual Studio 14 headers file.
The matcher now accept both variant (with 1 and 2 parameters).
Also added new unittests.
Similar issue than: [[ http://reviews.llvm.org/D18285 | review ]]
In the xstring.h header, the constructors are defined this way:
```
basic_string(const _Myt& _Right) [...]
basic_string(const _Myt& _Right, const _Alloc& _Al) [...]
```
Reviewers: alexfh, hokein
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18293
llvm-svn: 264069
Summary:
After patch https://lkml.org/lkml/2015/12/21/340 is introduced in
linux kernel, the random gap between stack and heap is increased
from 128M to 36G on 39-bit aarch64. And it is almost impossible
to cover this big range. So I think we need to disable randomized
virtual space on aarch64 linux.
Reviewers: kcc, llvm-commits, eugenis, zatrazz, dvyukov, rengolin
Subscribers: rengolin, aemerson, tberghammer, danalbert, srhines, enh
Differential Revision: http://reviews.llvm.org/D18003
llvm-svn: 264068
Davide Italiano