Note that "hasDotLocAndDotFile"-style debug info was already broken;
people wanting this functionality should implement it in the
AsmPrinter/DwarfWriter code.
llvm-svn: 89711
good nearby fuzzy match. Frequently the input is nearly correct, and just
showing the user the a nearby sensible match is enough to diagnose the problem.
- The "fuzzyness" is pretty simple and arbitrary, but worked on my three test
cases. If you encounter problems, or places you think FileCheck should have
guessed but didn't, please add test cases to PR5239.
For example, previously FileCheck would report this:
--
t.cpp:21:55: error: expected string not found in input
// CHECK: define void @_Z2f25f2_s1([[i64_i64_ty]] %a0)
^
<stdin>:19:30: note: scanning from here
define void @_Z2f15f1_s1(%1) nounwind {
^
<stdin>:19:30: note: with variable "i64_i64_ty" equal to "%0"
--
and now it also reports this:
--
<stdin>:27:1: note: possible intended match here
define void @_Z2f25f2_s1(%0) nounwind {
^
--
which makes it clear that the CHECK just has an extra ' %a0' in it, without
having to check the input.
llvm-svn: 89631
values, resolving references to them, and then removing the definitions.
If a template argument is set to an undefined value, we need to resolve
references to that argument to an explicit undefined value. The current code
leaves the reference to the template argument as it is, which causes an
assertion failure later when the definition of the template argument is
removed.
llvm-svn: 89581
The large code model is documented at
http://www.x86-64.org/documentation/abi.pdf and says that calls should
assume their target doesn't live within the 32-bit pc-relative offset
that fits in the call instruction.
To do this, we turn off the global-address->target-global-address
conversion in X86TargetLowering::LowerCall(). The first attempt at
this broke the lazy JIT because it can separate the movabs(imm->reg)
from the actual call instruction. The lazy JIT receives the address of
the movabs as a relocation and needs to record the return address from
the call; and then when that call happens, it needs to patch the
movabs with the newly-compiled target. We could thread the call
instruction into the relocation and record the movabs<->call mapping
explicitly, but that seems to require at least as much new
complication in the code generator as this change.
To fix this, we make lazy functions _always_ go through a call
stub. You'd think we'd only have to force lazy calls through a stub on
difficult platforms, but that turns out to break indirect calls
through a function pointer. The right fix for that is to distinguish
between calls and address-of operations on uncompiled functions, but
that's complex enough to leave for someone else to do.
Another attempt at this defined a new CALL64i pseudo-instruction,
which expanded to a 2-instruction sequence in the assembly output and
was special-cased in the X86CodeEmitter's emitInstruction()
function. That broke indirect calls in the same way as above.
This patch also removes a hack forcing Darwin to the small code model.
Without far-call-stubs, the small code model requires things of the
JITMemoryManager that the DefaultJITMemoryManager can't provide.
Thanks to echristo for lots of testing!
llvm-svn: 88984
- Used for running a single fixed command on a directory of files, with the
option of deriving a temporary input file from the test source.
llvm-svn: 88844
very robust) version of killall. Because I like making shiny new wheels out of
spare parts.
For use by buildbots when people insist on making cc1 infinite loop. :)
llvm-svn: 86484
