to obtain debug info about them.
Introduce helpers to access debug info for global variables. Also introduce a
helper that works for both local and global variables.
llvm-svn: 66541
allocating memory in the JIT. This is insanely inefficient, but
hey, most people implement their own memory managers anyway.
Patch by Eric Yew!
llvm-svn: 66472
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/gcc/libgcc2.c: In function '__muldi3':
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/gcc/libgcc2.c:567: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/gcc/libgcc2.c: In function '__lshrdi3':
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/gcc/libgcc2.c:421: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[5]: *** [libgcc/./_lshrdi3.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: *** [libgcc/./_muldi3.o] Error 1
make[5]: *** [libgcc/./_negdi2.o] Error 1
--- Reverse-merging (from foreign repository) r66415 into '.':
U include/llvm/BasicBlock.h
U include/llvm/ADT/ilist_node.h
U include/llvm/CodeGen/SelectionDAG.h
U include/llvm/CodeGen/MachineFunction.h
U include/llvm/CodeGen/MachineBasicBlock.h
U include/llvm/Function.h
llvm-svn: 66426
from 66280. I was unable to verify this with gcc-3.4.6, but with gcc-3.3 it
avoids the "base class with only non-default constructor in class without
a constructor" warning. Apparently that warning was promoted to an error
in gcc-3.4.
llvm-svn: 66424
whether a global is dead or not. This should fix PR3749 - linker adds
spurious use to appending globals. I can't reasonably add a testcase
for this, because the bc writer/reader strip dead constant users.
llvm-svn: 66404
validate an invariant so that the asmparser rejects a bad construct
instead of the verifier. Before:
llvm-as: assembly parsed, but does not verify as correct!
Invalid struct return type!
i64 (%struct.Type*, %struct.Type*)* @foo
after:
llvm-as: t.ll:5:8: functions with 'sret' argument must return void
define i64 @foo(%struct.Type* noalias nocapture sret %agg.result, %struct.Type* nocapture byval %t) nounwind {
^
Second, check that void is only used where allowed (in function return types) not in
arbitrary places, fixing PR3747 - Crash in llvm-as with void field in struct. We
now reject that example with:
$ llvm-as t.ll
llvm-as: t.ll:1:12: struct element can not have void type
%x = type {void}
^
llvm-svn: 66394
by checking that the top-level type of a gep is sized. This
causes us to reject the example with:
llvm-as: t2.ll:2:16: invalid getelementptr indices
getelementptr i32()* null, i32 1
^
llvm-svn: 66393
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
llvm-svn: 66339
signal handlers to prevent reentrance on unrelated things (a sigabort
where the handle bus errors) also, clear the signal mask so that the
signal doesn't infinitely reissue. This fixes rdar://6654827 -
Crash causes clang to loop
llvm-svn: 66330
1. When the JIT is asked to remove a function, updating it's
mapping to 0, we invalidate any function stubs used only
by that function. Now, also invalidate the JIT's mapping
from the GV the stub pointed to, to the address of the GV.
2. When dlsym stubs for cross-process JIT are enabled, do not
abort just because a named function cannot be found in the
JIT's process.
3. Fix various assumptions about when it is ok to use the lazy
resolver when non-lazy JITing is enabled.
llvm-svn: 66324
the same say the "test" instruction does in overflow cases,
so eliminating the test is only safe when those bits aren't
needed, as is the case for COND_E and COND_NE, or if it
can be proven that no overflow will occur. For now, just
restrict the optimization to COND_E and COND_NE and don't
do any overflow analysis.
llvm-svn: 66318
to find a tiny mouse hole to squeeze through, it struck
me that globals without a name can be considered internal
since they can't be referenced from outside the current
module. This patch makes GlobalOpt give them internal
linkage. Also done for aliases even though they always
have names, since in my opinion anonymous aliases should
be allowed for consistency with global variables and
functions. So if that happens one day, this code is ready!
llvm-svn: 66267
get nice and happy stack traces when we crash in an optimizer or codegen. For
example, an abort put in UnswitchLoops now looks like this:
Stack dump:
0. Program arguments: clang pr3399.c -S -O3
1. <eof> parser at end of file
2. per-module optimization passes
3. Running pass 'CallGraph Pass Manager' on module 'pr3399.c'.
4. Running pass 'Loop Pass Manager' on function '@foo'
5. Running pass 'Unswitch loops' on basic block '%for.inc'
Abort
llvm-svn: 66260
with multiple chain operands. This can occur when the scheduler
has added chain operands to a node that already has a chain
operand, in order to handle physical register dependencies.
This fixes an llvm-gcc bootstrap failure on x86-64 introduced
in r66058.
llvm-svn: 66240
The .cmi files are generated in $(ObjDir) and then copied to $(OcamlDir).
The ocamldep output references the .cmi files in $(ObjDir), so make kicks
off a dependent compile as soon as the local copy is generated. If the
copy to $(OcamlDir) is not complete at that point, the compiler will read
the partially copied file and complain about a "Corrupted compiled
interface". Searching $(ObjDir) first avoids this.
llvm-svn: 66217
INC64_32r and INC64_16r, because these instructions are encoded
differently on x86-64. This fixes JIT regressions on x86-64 in
kimwitu++ and others.
llvm-svn: 66207
If non constant local GV named A is used by a constant local GV named B (e.g. llvm.dbg.variable) and B is not used by anyone else then eliminate A as well as B.
In other words, debug info should not interfere in removal of unused GV.
--This life, and those below, will be ignored--
M test/Transforms/GlobalOpt/2009-03-03-dbg.ll
M lib/Transforms/IPO/GlobalOpt.cpp
llvm-svn: 66167
feels a kinship to machine stacks that grow down. Now we get
stuff like this:
Stack dump:
0. Program arguments: clang clang_crash_Iw2Osj.mi
1. /Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/xmmintrin.h:624:1: parsing function body '_mm_cvtpi16_ps'
2. /Developer/SDKs/MacOSX10.5.sdk/usr/lib/gcc/i686-apple-darwin9/4.0.1/include/xmmintrin.h:624:1: in compound statement ('{}')
Abort
llvm-svn: 66145
This invalidates the stubs in the resolver map when they are no longer referenced,
and should the JIT memory manager ever pick up a deallocateStub interface, the
JIT could reclaim the memory for unused stubs as well.
llvm-svn: 66141
arbitrary functions to be run when a crash happens. Delete
RemoveDirectoryOnSignal as it is dead and has never had clients.
Change PrintStackTraceOnErrorSignal to be implemented in terms of
AddSignalHandler.
I updated the Win32 versions of these APIs, but can't test them.
If there are any problems, I'd be happy to fix them as well.
llvm-svn: 66072
John Criswell