which in a fit of zeal wanted to walk the entire translation unit,
and replace it with a new checker that walks the types of declarations
nested within the class. Also, look into templates when doing this.
llvm-svn: 111357
from the LHS should disable reconsidering that pred on the
RHS. However, knowing something about the pred on the RHS
shouldn't disable subsequent additions on the RHS from
happening.
llvm-svn: 111349
than GCC 4.2 here when building 32-bit (where GCC will allow
allocation of an array for which we can't get a valid past-the-end
pointer), and emulate its odd behavior in 64-bit where it only allows
63 bits worth of storage in the array. The former is a correctness
issue; the latter is harmless in practice (you wouldn't be able to use
such an array anyway) and helps us pass a GCC DejaGNU test.
Fixes <rdar://problem/8212293>.
llvm-svn: 111338
the resulting function from the .o file DWARF didn't make it into the final
executable. I recently changed the way FindFunctions() worked in the DWARF
with debug map case that caused regressions in our test suite for dead
stripped functions. The previous changes allowed us to leverage the powerful
searching added to the DWARF parser (search by full name, basename, selector,
or method name), without having to chop up the symbol names from the symbol
table and do any special parsing of the names to extract the basename,
selector or method. Previously we would look through the symbol table for
matches first, then try and find the .o file with DWARF for that symbol and
only search those .o files. Now we let the DWARF for the .o file search using
the new search styles, and filter out any functions that didn't make it.
llvm-svn: 111322
(e.g. errs()) fails in close() due to (e.g.) a broken pipe. As
previously written, the had_error() flag would get set and then
the raw_ostream dtor would report a fatal error. There is nothing
the client can do about this and we have no way to report the error,
so just eat it.
llvm-svn: 111321
where the step value is an induction variable from an outer loop, to
avoid trouble trying to re-expand such expressions. This effectively
hides such expressions from indvars and lsr, which prevents them
from getting into trouble.
llvm-svn: 111317
the local block. Resolve references to those indices to a new base register.
For simplification and testing purposes, a new virtual base register is
allocated for each frame index being resolved. The result is truly horrible,
but correct, code that's good for exercising the new code paths.
Next up is adding thumb1 support, which should be very simple. Following that
will be adding base register re-use and implementing a reasonable ARM
heuristic for when a virtual base register should be generated at all.
llvm-svn: 111315
John McCall