void bork() {
int *address = 0;
*address = 0;
}
It's compiled into LLVM code that looks like this:
define void @bork() noreturn nounwind {
entry:
unreachable
}
This is bad on some platforms (like PPC) because it will generate the label for
the function but no body. The label could end up being associated with some
non-code related stuff, like a section. This places a "trap" instruction if the
SimplifyCFG pass removed all code from the function leaving only one
"unreachable" instruction.
llvm-svn: 46387
delete a node even if it was not dead in some cases. Instead, just add it to
the worklist. Also, make sure to use the CombineTo methods, as it was doing
things that were unsafe: the top level combine loop could touch dangling memory.
This fixes CodeGen/Generic/2008-01-25-dag-combine-mul.ll
llvm-svn: 46384
some previously missing NULL pointer checks.
Modified the UninitializedValues analysis to not expect that every Expr* at the
block-level is a block-level expression (we probably need to change the name of
such expressions to something truer to their meaning).
llvm-svn: 46380
Renamed RValueConjunctiveUnequal to RValInequalityANDSet.
Refactored add/subtract/multiple (and now divide) operations for
RValEqualityORSet to be based on a single template function.
llvm-svn: 46374
was actually passing a completely incorrect size to sys_icache_invalidate.
Instead of having the JITEmitter do this (which doesn't have the correct
size), just make the target sync its own stubs.
llvm-svn: 46354
arrays. Also, as a convenience, don't barf, just
return false, if someone calls isTruncStoreLegal
or isLoadXLegal with an extended type for the in
memory type.
llvm-svn: 46352
This is a modified version of a patch by Eli Friedman. This version passes all of the clang tests and supports vectors:-)
Note that Eli and I are still unsatisfied the implementation of CheckInitializerListTypes(). We'd like to find a more elegant implementation. Nevertheless, this is a complex part of the standard (and may be hard to simplify). Since the complexity is localized to this routine, we can iterate without too much disruption:-)
llvm-svn: 46339
information is not separated into a "base" and "sub" type. Eventually the
value-tracking logic will know about LValues and RValues, but not about
specialized LValues and RValues; separating the "kind" information into bits
indicating whether an ExprValue is an LValue or an RValue from the bits that
specify the actual value type makes this separation easier.
llvm-svn: 46329
Bill Wendling