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
This is a re-commit of r264022 with a fix for MSVC. The issue there was
that the code was running DefinedAtom::~Atom() for some value and instead
needed to cast to Atom before running ~Atom. Original commit message follows.
Currently each File contains an BumpPtrAllocator in which Atom's are
allocated. Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.
Now each File actually owns its Atom's using an OwningAtomPtr. This
is analygous to std::unique_ptr and may be replaced by it if possible.
An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another. The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's. This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.
Should hopefully fix the remaining leaks. Will keep an eye on the bots to
make sure.
llvm-svn: 264067
While we correctly assigned an inheritance model for the source of a
member pointer upcast, we did not do so for the destination.
This fixes PR27030.
llvm-svn: 264065
Improve vector extension of vectors on hardware without dedicated VSEXT/VZEXT instructions.
We already convert these to SIGN_EXTEND_VECTOR_INREG/ZERO_EXTEND_VECTOR_INREG but can further improve this by using the legalizer instead of prematurely splitting into legal vectors in the combine as this only properly helps for lowering to VSEXT/VZEXT.
Removes a lot of unnecessary any_extend + mask pattern - (Fix for PR25718).
Reapplied with a fix for PR26953 (missing vector widening legalization).
Differential Revision: http://reviews.llvm.org/D17932
llvm-svn: 264062
Summary:
Also renamed li_simm7 to li16_imm since it's not a simm7 and has an unusual
encoding (it's a uimm7 except that 0x7f represents -1).
Reviewers: vkalintiris
Subscribers: dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D18145
llvm-svn: 264056
"import ... from '...';" and "export ... from '...';" should be treated
the same as goog.require/provide/module/forwardDeclare calls.
Patch by Martin Probst.
llvm-svn: 264055
Summary:
We can't check the error message for this one because there's another lw/sw
available that covers a larger range. We therefore check the transition
between the two sizes.
Reviewers: vkalintiris
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D18144
llvm-svn: 264054
It's a bug fix.
For rerolled loops SE trip count remains unchanged. It leads to incorrect work of the next passes.
My patch just resets SE info for rerolled loop forcing SE to re-evaluate it next time it requested.
I also added a verifier call in the exisitng test to be sure no invalid SE data remain. Without my fix this test would fail with -verify-scev.
Differential Revision: http://reviews.llvm.org/D18316
llvm-svn: 264051
When a tls access is optimized, a group of relocations is converted at a
time.
We were already skipping relocations that were optimized out in
relocate, but not in scanRelocs.
This is a small optimization. I got here while working on a patch that
will always keep scanRelocs and relocate in sync.
llvm-svn: 264048
R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX relocations were added in latest ABI:
https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf
They should be generated instead of R_X86_64_GOTPCREL for cases
when relaxation is possible. Currently this patch just process them in the
same way like R_X86_64_GOTPCREL. That should work for now
and we can implement relaxations later.
There is no testcases provided as I think there is no way to generate
such relocations using llvm-mc atm.
Differential revision: http://reviews.llvm.org/D18301
llvm-svn: 264043
Adding support for section names with special characters in them (e.g. "/").
GCC successfully compiles such section names.
This also fixes PR24520.
Differential Revision: http://reviews.llvm.org/D15678
llvm-svn: 264038
Summary: A checker (will be uploaded after this patch) needs to check implicit casts. Existing generic matcher "has" ignores implicit casts and parenthesized expressions and no specific matcher for matching return value expression preexisted. The patch adds such a matcher (hasReturnValue).
Reviewers: klimek, sbenza
Subscribers: xazax.hun, klimek, cfe-commits
Patch by Ádám Balogh!
Differential Revision: http://reviews.llvm.org/D17986
llvm-svn: 264037
Now local symbols have SymbolBody so we can handle all kind of symbols
in the GotSection::addEntry method. The patch moves the code from
addMipsLocalEntry to addEntry. NFC.
Differential Revision: http://reviews.llvm.org/D18302
llvm-svn: 264032
Some basic checks next to the implementation should futher lower the
possibility to introduce regressions. (Note that this would have catched
the ordering issue fixed in rL258866 and pointed to rL263940.)
The tests are implementation dependent in one point because they assume that
thread ids are assigned in ascending order. This is not defined by the standard
but currently ensured in libomp. We have to think about another way of ordering
the threads should this ever be subject to change...
Note that this isn't aiming at replacing the implementation independent
test-suite at https://github.com/OpenMPToolsInterface/ompt-test-suite!
Differential Revision: http://reviews.llvm.org/D16715
llvm-svn: 264027
IsExact shouldn't be set to true in WeakObjectProfileTy::getBaseInfo
when the receiver is a class because having a class as the receiver
doesn't guarantee that the Base is exact.
This is a follow-up to r263818.
rdar://problem/25208167
llvm-svn: 264025
This reverts commit r264022.
This breaks the Window's bots which don't like that i'm calling ~Atom when
the this pointer is a sublcass of Atom.
Reverting for now until I try find a better fix. I tried using std::unique_ptr with
a custom deleter as a quick fix, but it didn't work well in the YAML parser.
llvm-svn: 264023
Currently each File contains an BumpPtrAllocator in which Atom's are
allocated. Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.
Now each File actually owns its Atom's using an OwningAtomPtr. This
is analygous to std::unique_ptr and may be replaced by it if possible.
An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another. The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's. This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.
Should hopefully fix the remaining leaks. Will keep an eye on the bots to
make sure.
llvm-svn: 264022
When LIT parallelizes the profraw file generation we need to generate unique temp filenames then clean them up after the driver executes.
llvm-svn: 264021
With this change, the class
struct A {
A(int _i);
~A();
int foo(double d);
double bar(A *a) { return 1.3; }
};
appears in the VS2015 Locals Window as
D 0x02dbb378 struct A
|- DeclKind CXXRecord
|- Members
|- [0] implicit struct A
|- [1] Constructor {A(int _i)}
|- [2] Destructor {~A()}
|- [3] Method {int foo(double d)}
|- [4] Method {double bar(struct A *)}
|- [Raw View] /* Other stuff */
Note that these changes only benefit VS2015 as
VS2013 does not have views and only displays the
struct name "A", but the change does no apparent
harm in VS2013, so is still a win.
llvm-svn: 264020
Summary:
This patch adds base support for codegen of the target directive on the NVPTX device.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D17877
Reworked test case after buildbot failure on windows.
Updated patch to integrate r263837 and test case nvptx_target_firstprivate_codegen.cpp.
llvm-svn: 264018
Pete Cooper