| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cleanups.
Also, change code in tablegen which printed a message and then called
"exit(1)" to use PrintFatalError, instead.
This fixes instances where an empty output file was left behind after
a failed tablegen invocation, which would confuse subsequent ninja
runs into not attempting to rebuild.
Differential Revision: http://reviews.llvm.org/D9608
llvm-svn: 237058
|
|
|
|
| |
llvm-svn: 236398
|
|
|
|
|
|
| |
unnecessary curly braces. NFC
llvm-svn: 236397
|
|
|
|
|
|
| |
end of previous line. NFC
llvm-svn: 236206
|
|
|
|
| |
llvm-svn: 236205
|
|
|
|
|
|
| |
Fold an assignment into an if. Use auto on the result of a couple dyn_casts. NFC
llvm-svn: 236204
|
|
|
|
| |
llvm-svn: 236089
|
|
|
|
| |
llvm-svn: 236088
|
|
|
|
|
|
| |
cast which asserts internally. NFC
llvm-svn: 236087
|
|
|
|
| |
llvm-svn: 236083
|
|
|
|
| |
llvm-svn: 235697
|
|
|
|
| |
llvm-svn: 235696
|
|
|
|
| |
llvm-svn: 235482
|
|
|
|
|
|
| |
seem to execute in our codebase today and date back to a time when there was an allocation in this function.
llvm-svn: 235481
|
|
|
|
|
|
| |
Previously the code was accidentally checking if 'this' was an IntRecTy which it can't be since 'this' is a BitRecTy. Looking back at the history it appears it was intended to check RHS.
llvm-svn: 235477
|
|
|
|
| |
llvm-svn: 235476
|
|
|
|
|
|
|
|
| |
before being dereferenced."
Turns out I misread the parentheses. Though I'm pretty sure its always a RecordRecTy and non of the callers really seem to expect null. But until I'm completely sure I'm going to revert this.
llvm-svn: 235469
|
|
|
|
| |
llvm-svn: 235468
|
|
|
|
| |
llvm-svn: 235467
|
|
|
|
|
|
| |
StringRecTy object.
llvm-svn: 235466
|
|
|
|
|
|
| |
singleton object created by UnsetInit::get(). Makes it more consistent with the other types.
llvm-svn: 235465
|
|
|
|
|
|
| |
being dereferenced.
llvm-svn: 235463
|
|
|
|
|
|
| |
These add no value but can make a class non-trivially copyable. NFC.
llvm-svn: 234688
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 234586
|
|
|
|
| |
llvm-svn: 230909
|
|
|
|
| |
llvm-svn: 229422
|
|
|
|
|
|
|
|
|
|
| |
This allows IDEs to recognize the entire set of header files for
each of the core LLVM projects.
Differential Revision: http://reviews.llvm.org/D7526
Reviewed By: Chris Bieneman
llvm-svn: 228798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was generated by a clang tidy checker that is being open sourced.
The documentation of that checker is the following:
/// The emptiness of a container should be checked using the empty method
/// instead of the size method. It is not guaranteed that size is a
/// constant-time function, and it is generally more efficient and also shows
/// clearer intent to use empty. Furthermore some containers may implement the
/// empty method but not implement the size method. Using empty whenever
/// possible makes it easier to switch to another container in the future.
Patch by Gábor Horváth!
llvm-svn: 226161
|
|
|
|
|
|
|
|
|
| |
Clang's static analyzer found several potential cases of undefined
behavior, use of un-initialized values, and potentially null pointer
dereferences in tablegen, Support, MC, and ADT. This cleans them up
with specific assertions on the assumptions of the code.
llvm-svn: 224154
|
|
|
|
| |
llvm-svn: 224005
|
|
|
|
| |
llvm-svn: 223998
|
|
|
|
|
|
|
|
| |
ownership and deletion of the values.
Ideally we would store the MultiClasses by value directly in the maps, but I had some trouble with that before and this at least fixes the leak.
llvm-svn: 223997
|
|
|
|
|
|
|
|
|
|
| |
ownership and deletion of the values."
Upon further review I think the MultiClass is being copied into the map instead of being moved due to the copy constructor on the nested Record type. This ultimately got exposed when the vector in DefPrototype vector was changed to hold unique_ptrs in another commit. This caused gcc 4.7 to fail due to the use of the copy constructor on unique_ptr with the error pointing back to one of the insert calls from this commit. Not sure why clang was able to build.
This reverts commit 710cdf729f84b428bf41aa8d32dbdb35fff79fde.
llvm-svn: 222971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
memory leaks."
The bots started failing with the error below. I suspect this revision was the cause.
FAILED: /home/bb/bin/g++47 -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -O3 -DNDEBUG -Ilib/TableGen -I/home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen -Iinclude -I/home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include -fno-exceptions -fno-rtti -MMD -MT lib/TableGen/CMakeFiles/LLVMTableGen.dir/TGParser.cpp.o -MF "lib/TableGen/CMakeFiles/LLVMTableGen.dir/TGParser.cpp.o.d" -o lib/TableGen/CMakeFiles/LLVMTableGen.dir/TGParser.cpp.o -c /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_tempbuf.h:62:0,
from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_algo.h:64,
from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/algorithm:63,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/ADT/StringRef.h:13,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGLexer.h:17,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.h:17,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp:14:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_construct.h: In instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = std::unique_ptr<llvm::Record>; _Args = {const std::unique_ptr<llvm::Record, std::default_delete<llvm::Record> >&}]':
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_uninitialized.h:77:3: required from 'static _ForwardIterator std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<const std::unique_ptr<llvm::Record>*, std::vector<std::unique_ptr<llvm::Record> > >; _ForwardIterator = std::unique_ptr<llvm::Record>*; bool _TrivialValueTypes = false]'
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_uninitialized.h:119:41: required from '_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator<const std::unique_ptr<llvm::Record>*, std::vector<std::unique_ptr<llvm::Record> > >; _ForwardIterator = std::unique_ptr<llvm::Record>*]'
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_uninitialized.h:260:63: required from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator = __gnu_cxx::__normal_iterator<const std::unique_ptr<llvm::Record>*, std::vector<std::unique_ptr<llvm::Record> > >; _ForwardIterator = std::unique_ptr<llvm::Record>*; _Tp = std::unique_ptr<llvm::Record>]'
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_vector.h:310:9: required from 'std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp = std::unique_ptr<llvm::Record>; _Alloc = std::allocator<std::unique_ptr<llvm::Record> >]'
/home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/TableGen/Record.h:1664:8: required from 'constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = std::basic_string<char>&; _U2 = llvm::MultiClass; <template-parameter-2-3> = void; _T1 = std::basic_string<char>; _T2 = llvm::MultiClass]'
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:273:72: required from 'constexpr std::pair<typename std::__decay_and_strip<_T1>::__type, typename std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _T2&&) [with _T1 = std::basic_string<char>&; _T2 = llvm::MultiClass; typename std::__decay_and_strip<_T2>::__type = llvm::MultiClass; typename std::__decay_and_strip<_T1>::__type = std::basic_string<char>]'
/home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp:2295:78: required from here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_construct.h:77:7: error: use of deleted function 'std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = llvm::Record; _Dp = std::default_delete<llvm::Record>]'
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/memory:86:0,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/ADT/STLExtras.h:25,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:14,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/include/llvm/Support/SourceMgr.h:19,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.h:19,
from /home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/lib/TableGen/TGParser.cpp:14:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/unique_ptr.h:262:7: error: declared here
ninja: build stopped: subcommand failed.
llvm-svn: 222970
|
|
|
|
|
|
|
| |
The previous patch had effect, but missed this one. It seems MSVC
gets ADL-confused by the calls where the first argument is a function call?
llvm-svn: 222968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was failing with this kind of error:
C:\b\build\slave\CrWinClang\build\src\third_party\llvm\lib\TableGen\TGParser.cpp(1243) : error C2668: 'llvm::make_unique' : ambiguous call to overloaded function
C:\b\build\slave\CrWinClang\build\src\third_party\llvm\include\llvm/ADT/STLExtras.h(408): could be 'std::unique_ptr<llvm::Record,std::default_delete<_Ty>> llvm::make_unique<llvm::Record,std::string,llvm::SMLoc&,llvm::RecordKeeper&,bool>(std::string &&,llvm::SMLoc &,llvm::RecordKeeper &,bool &&)'
with
[
_Ty=llvm::Record
]
C:\b\depot_tools\win_toolchain\vs2013_files\win8sdk\bin\..\..\VC\include\memory(1637): or 'std::unique_ptr<llvm::Record,std::default_delete<_Ty>> std::make_unique<llvm::Record,std::string,llvm::SMLoc&,llvm::RecordKeeper&,bool>(std::string &&,llvm::SMLoc &,llvm::RecordKeeper &,bool &&)' [found using argument-dependent lookup]
with
[
_Ty=llvm::Record
]
while trying to match the argument list '(std::string, llvm::SMLoc, llvm::RecordKeeper, bool)'
llvm-svn: 222967
|
|
|
|
| |
llvm-svn: 222966
|
|
|
|
| |
llvm-svn: 222965
|
|
|
|
|
|
| |
of the values.
llvm-svn: 222957
|
|
|
|
| |
llvm-svn: 222955
|
|
|
|
|
|
| |
internally.
llvm-svn: 222948
|
|
|
|
|
|
| |
At least one spot of weird ownership passing that needs some future cleanup.
llvm-svn: 222947
|
|
|
|
| |
llvm-svn: 218999
|
|
|
|
| |
llvm-svn: 218462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By class-instance values I mean 'Class<Arg>' in 'Class<Arg>.Field' or in
'Other<Class<Arg>>' (syntactically s SimpleValue). This is to differentiate
from unnamed/anonymous record definitions (syntactically an ObjectBody) which
are not affected by this change.
Consider the testcase:
class Struct<int i> {
int I = !shl(i, 1);
int J = !shl(I, 1);
}
class Class<Struct s> {
int Class_J = s.J;
}
multiclass MultiClass<int i> {
def Def : Class<Struct<i>>;
}
defm Defm : MultiClass<2>;
Before this fix, DefmDef.Class_J yields !shl(I, 1) instead of 8.
This is the sequence of events. We start with this:
multiclass MultiClass<int i> {
def Def : Class<Struct<i>>;
}
During ParseDef the anonymous object for the class-instance value is created:
multiclass Multiclass<int i> {
def anonymous_0 : Struct<i>;
def Def : Class<NAME#anonymous_0>;
}
Then class Struct<i> is added to anonymous_0. Also Class<NAME#anonymous_0> is
added to Def:
multiclass Multiclass<int i> {
def anonymous_0 {
int I = !shl(i, 1);
int J = !shl(I, 1);
}
def Def {
int Class_J = NAME#anonymous_0.J;
}
}
So far so good but then we move on to instantiating this in the defm
by substituting the template arg 'i'.
This is how the anonymous prototype looks after fully instantiating.
defm Defm = {
def Defmanonymous_0 {
int I = 4;
int J = !shl(I, 1);
}
Note that we only resolved the reference to the template arg. The
non-template-arg reference in 'J' has not been resolved yet.
Then we go on to instantiating the Def prototype:
def DefmDef {
int Class_J = NAME#anonymous_0.J;
}
Which is resolved to Defmanonymous_0.J and then to !shl(I, 1).
When we fully resolve each record in a defm, Defmanonymous_0.J does get set
to 8 but that's too late for its use.
The patch adds a new attribute to the Record class that indicates that this
def is actually a class-instance value that may be *used* by other defs in a
multiclass. (This is unlike regular defs which don't reference each other and
thus can be resolved indepedently.) They are then fully resolved before the
other defs while the multiclass is instantiated.
I added vg_leak to the new test. I am not sure if this is necessary but I
don't think I have a way to test it. I can also check in without the XFAIL
and let the bots test this part.
Also tested that X86.td.expanded and AAarch64.td.expanded were unchange before
and after this change. (This issue triggering this problem is a WIP patch.)
Part of <rdar://problem/17688758>
llvm-svn: 217886
|
|
|
|
| |
llvm-svn: 216798
|
|
|
|
|
|
| |
Followup to r215086.
llvm-svn: 216757
|
|
|
|
|
|
|
|
|
|
| |
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
|
|
|
|
| |
llvm-svn: 216350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This does nothing but remove the Record from the map, and
then re-add it, without actually changing it in between.
The Record's Name used to be changed before re-adding it
when the code was first committed in r137232, but the
name-changing lines were removed in r142510, and since
then this code seems to do nothing.
This was also the only caller of removeClass or removeDef,
so now RecordKeeper owns its Records unconditionally,
and could be unique_ptr-ified.
llvm-svn: 216349
|