typo. This can happen with context-sensitive keywords like "super",
when typo correction didn't know that "super" wasn't permitted in this
context.
llvm-svn: 117372
loaded/parsed. Should add timers to this eventually.
Delay getting a full UnwindPlan if it's possible to unwind with
just a fast UnwindPlan. This keeps us from reading the eh_frame
section unless we hit something built -fomit-frame pointer or we
hit a frame with no symbol (read: no start address) available.
It doesn't look like it is correctly falling back to using the
full UnwindPlan to provide additional registers that the fast
UnwindPlan doesn't supply; e.g. go to the middle of a stack and
ask for r12 and it will show you the value of r12 in frame 0.
That's a bug for tomorrow.
llvm-svn: 117361
The SPU ABI does not mention v64, and all examples
in C suggest v128 are treated similarily to arrays,
we use array alignment for v64 too. This makes the
alignment of e.g. [2 x <2 x i32>] behave "intuitively"
and similar to as if the elements were e.g. i32s.
This also makes an "unaligned store" test to be
aligned, with different (but functionally equivalent)
code generated.
llvm-svn: 117360
There's probably still significant padding waste on x86-64 UNIXen, but
the difference in 32-bit compiles should be significant.
There are a lot of Expr nodes left that could lose a word this way.
llvm-svn: 117359
until after we've checked/promoted the argument. Hopefully fixes the
Emacs regression due to my recent change that expanded type-checking
in the presence of K&R function definitions.
llvm-svn: 117353
- tags with C linkage should ignore visibility=hidden
- functions and variables with explicit visibility attributes should
ignore the linkage of their types
Either of these should be sufficient to fix PR8457.
Also, FileCheck-ize a test case.
llvm-svn: 117351
gets to be a problem if you have a unbounded stack walk.
Fix the CFA sanity checks. Add one to the arch default UnwindPlan run which was giving
one extra stack frame on the main thread. Fix a couple of logging lines that had their
argument order incorrect.
llvm-svn: 117350
it logs the function calls, their arguments and the return values. This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done. It currently does not
attempt to log all the functions, just the most important ones. I will be
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).
Update the Python build scripts to re-build the swig C++ file whenever
the python-extensions.swig file is modified.
Correct the help for 'log enable' command (give it the correct number & type of
arguments).
llvm-svn: 117349
covariant/contravariant overrides and implementations, but do so under
control of a new flag (-Wno-objc-covariant-overrides, which yes does cover
contravariance too).
*At least* the covariance cases will probably be enabled by default shortly,
but that's not totally uncontroversial.
llvm-svn: 117346
getCanonicalType() to make sure that the type we got back is actually
canonical. This is the case for most types, which always build a
canonical type when given canonical components. However, some types that
involve expressions in their canonicalization (e.g., array types with
dependent sizes) don't always build canonical types from canonical
components, because there is no such thing as a "canonical"
expression. Therefore, we do this extra mapping to ensure that the
canonical types we store are actually canonical.
llvm-svn: 117344
prologue profiling.
Change the log print statements to elide the thread number, make
some of them only print when IsLogVerbose().
Add a couple of sanity checks for impossible CFA values so backtraces
don't go too far off into the weeds.
llvm-svn: 117343
globals memory space gets assigned a symbolic value, but that value was not being used for lazy symbolication
of fields of globals. This could result in cases where bogus null dereferences were being reported.
Fixes PR 8440.
llvm-svn: 117336
do not double-count the duplicate instructions by counting once from the
beginning and again from the end. Keep track of where the duplicates from
the beginning ended and don't go past that point when counting duplicates
at the end. Radar 8589805.
This change causes one of the MC/ARM/simple-fp-encoding tests to produce
different (better!) code without the vmovne instruction being tested.
I changed the test to produce vmovne and vmoveq instructions but moving
between register files in the opposite direction. That's not quite the same
but predicated versions of those instructions weren't being tested before,
so at least the test coverage is not any worse, just different.
llvm-svn: 117333
instructions separately from the count of non-predicated instructions. The
instruction count is used in places to determine how many instructions to
copy, predicate, etc. and things get confused if that count includes the
extra cost for microcoded ops.
llvm-svn: 117332