| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 71793
|
| |
|
|
|
|
|
|
| |
template to the FunctionDecls from which they were instantiated. This
is a necessary first step to support instantiation of the definitions
of such functions, but by itself does essentially nothing.
llvm-svn: 71792
|
| |
|
|
| |
llvm-svn: 71791
|
| |
|
|
| |
llvm-svn: 71790
|
| |
|
|
|
|
|
|
|
|
|
| |
Create an OpInit class to serve as a base for all operation Inits.
Move parsing of operation constructs to separate functions and reference
from multiple places.
Add some commented out new operations. Coming soon.
llvm-svn: 71789
|
| |
|
|
| |
llvm-svn: 71788
|
| |
|
|
|
|
|
| |
If we're resolving a list element access and we're given a VarInit,
return a new VarListElementInit referencing the VarInit.
llvm-svn: 71787
|
| |
|
|
| |
llvm-svn: 71786
|
| |
|
|
|
|
| |
Part one of many.
llvm-svn: 71785
|
| |
|
|
| |
llvm-svn: 71784
|
| |
|
|
|
|
| |
adding another copy.
llvm-svn: 71783
|
| |
|
|
|
|
|
|
| |
- Reformatting.
- Use while() instead of do-while().
- Move simple constructors into .h file.
llvm-svn: 71782
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 71781
|
| |
|
|
|
|
| |
all.
llvm-svn: 71780
|
| |
|
|
|
|
| |
assertion is failing for some tests.
llvm-svn: 71779
|
| |
|
|
|
|
| |
with sentinel attribute.
llvm-svn: 71778
|
| |
|
|
| |
llvm-svn: 71776
|
| |
|
|
| |
llvm-svn: 71775
|
| |
|
|
|
|
|
|
|
|
|
| |
- Otherwise we emit internal names with embedded '\01' characters,
which confuses some tools.
- Ideally all the code which wants to get a "display name" for the
given function should follow one code path, but this should be a
monotonic improvement for now.
llvm-svn: 71774
|
| |
|
|
|
|
|
| |
declared as a "class", or vice-versa. This warning is under the
control of -Wmismatched-tags, which is off by default.
llvm-svn: 71773
|
| |
|
|
| |
llvm-svn: 71772
|
| |
|
|
| |
llvm-svn: 71771
|
| |
|
|
|
|
|
|
|
|
| |
to low-level sync operations.
The only one present at the moment is MemoryFence(), and only for the platforms
for which I could easily discern the proper way to do it. If your favorite platform
isn't represented, patches are welcome!
llvm-svn: 71770
|
| |
|
|
|
|
| |
last use.
llvm-svn: 71769
|
| |
|
|
| |
llvm-svn: 71763
|
| |
|
|
|
|
|
| |
emit the correct "display name". I suspect we need more work here, see
FIXME for example.
llvm-svn: 71761
|
| |
|
|
|
|
| |
don't check covariance but that's next.
llvm-svn: 71759
|
| |
|
|
|
|
|
|
|
| |
llvm.eh.sjlj.* for better clarity as to their purpose and scope. Add
a description of llvm.eh.sjlj.setjmp to ExceptionHandling.html.
(llvm.eh.sjlj.longjmp documentation coming when that implementation is
added).
llvm-svn: 71758
|
| |
|
|
|
|
| |
asm construct into an assertion failure.
llvm-svn: 71757
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template<typename T>
struct X {
struct Inner;
};
template struct X<int>::Inner;
This change is larger than it looks because it also fixes some
a problem with nested-name-specifiers and tags. We weren't requiring
the DeclContext associated with the scope specifier of a tag to be
complete. Therefore, when looking for something like "struct
X<int>::Inner", we weren't instantiating X<int>.
This, naturally, uncovered a problem with member pointers, where we
were requiring the left-hand side of a member pointer access
expression (e.g., x->*) to be a complete type. However, this is wrong:
the semantics of this expression does not require a complete type (EDG
agrees).
Stuart vouched for me. Blame him.
llvm-svn: 71756
|
| |
|
|
|
|
| |
Radar 6867696
llvm-svn: 71750
|
| |
|
|
|
|
|
| |
Basically, there was a situation where it was getting an empty vector and doing
a .back() on that. Which isn't cool.
llvm-svn: 71746
|
| |
|
|
|
|
|
|
| |
block with its unique predecessor. Change the code to assert if that is not
the case, instead of trying to handle situations where the block has
multiple predecessors.
llvm-svn: 71744
|
| |
|
|
|
|
|
|
|
| |
of exception handling builtin sjlj targets in functions turns out not to
be necessary. Marking the intrinsic implementation in the .td file as
defining all registers is sufficient to get the context saved properly by
the containing function.
llvm-svn: 71743
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dan was trying to catch the case where a basic block ends with a conditional
branch to the fall-through block. In this case, all the instructions have
been moved out of FromBBI, leaving it empty. It cannot end with a
conditional branch. As the existing comment indicates, it will always fall
through to the next block. If the block already had the next block (NBB)
listed as a successor, the preceding loop has a check for that and does not
remove it. Thus, we need to check and add the successor only when it is
not already listed.
With Dan's change, the empty block often ends up with the fall-through
successor listed twice. This exposed the problem in pr4195, where
CodePlacementOpt did not handle the same predecessor listed more than once.
It is also at least partially responsible for pr4202 and probably a similar
issue with Thumb branches being out of range.
llvm-svn: 71742
|
| |
|
|
| |
llvm-svn: 71741
|
| |
|
|
| |
llvm-svn: 71740
|
| |
|
|
|
|
| |
field name. No functional changes.
llvm-svn: 71739
|
| |
|
|
| |
llvm-svn: 71738
|
| |
|
|
|
|
| |
dispatch arguments which have sentinel attribute.
llvm-svn: 71737
|
| |
|
|
|
|
| |
debug info.
llvm-svn: 71736
|
| |
|
|
|
|
| |
few places
llvm-svn: 71735
|
| |
|
|
| |
llvm-svn: 71734
|
| |
|
|
| |
llvm-svn: 71730
|
| |
|
|
| |
llvm-svn: 71726
|
| |
|
|
| |
llvm-svn: 71725
|
| |
|
|
| |
llvm-svn: 71724
|
| |
|
|
|
|
|
|
| |
compared to gcc. This is worrisome, but I believe we are doing the
"correct" thing, and if I recall correctly I previously verified this
versus MSVC.
llvm-svn: 71723
|
| |
|
|
|
|
|
|
|
|
|
|
| |
booleans. This gives a better indication of what the "addReg()" is
doing. Remembering what all of those booleans mean isn't easy, especially if you
aren't spending all of your time in that code.
I took Jakob's suggestion and made it illegal to pass in "true" for the
flag. This should hopefully prevent any unintended misuse of this (by reverting
to the old way of using addReg()).
llvm-svn: 71722
|
| |
|
|
| |
llvm-svn: 71721
|