--assert, --classpath).
- Requires providing some option parameters to over-ride rendering in
order to match gcc. There may be a cleaner way to do this (probably
by introducing a new option type for long JoinedOrSeparate forms).
llvm-svn: 62825
- Unlike groups (which gather distinct but related options), aliases
are for options like '--all-warnings' which are effectively treated
like some other option ('-Wall') both in the driver logic and when
passing to tools.
llvm-svn: 62820
initializers, so that we are within the appropriate subobject after
we've processed a multi-designator designation. We're matching GCC and
EDG's behavior on all examples I've found thus far.
*Huge* thanks to Eli Friedman for pointing out my fundamental
misunderstanding of "current object" in the C99 spec.
llvm-svn: 62812
to "C ^ 1" is only valid when C is known to be either 0 or 1. Most of the
similar foldings in this function only handle "i1" types, but this one appears
intentionally written to handle larger integer types. If C has an integer
type larger than "i1", this needs to check if the high bits of a boolean
are known to be zero. I also changed the comment to describe this folding as
"C ^ 1" instead of "~C", since that is what the code does and since the latter
would only be valid for "i1" types. The good news is that most LLVM targets
use TargetLowering::ZeroOrOneBooleanContent so this change will not disable
the optimization; the bad news is that I've been unable to come up with a
testcase to demonstrate the problem.
I have also removed a "FIXME" comment for folding "select C, X, 0" to "C & X",
since the code looks correct to me. It could be made more aggressive by not
limiting the type to "i1", but that would then require checking for
TargetLowering::ZeroOrNegativeOneBooleanContent. Similar changes could be
done for the other SELECT foldings, but it was decided to be not worth the
trouble and complexity (see e.g., r44663).
llvm-svn: 62790
Simplify x+0 to x in unsafe-fp-math mode. This avoids a bunch of
redundant work in many cases, because in unsafe-fp-math mode,
ISD::FADD with a constant is considered free to negate, so the
DAGCombiner often negates x+0 to -0-x thinking it's free, when
in reality the end result is -x, which is more expensive than x.
Also, combine x*0 to 0.
This fixes PR3374.
llvm-svn: 62789
their associated APIs. We no longer need separate SymbolData objects
for fields, variables, etc. Instead, we now associated symbols with
the "rvalue" of a MemRegion (i.e., the value stored at that region).
Now we only have two kinds of SymbolData objects: SymbolRegionRValue
and SymbolConjured.
This cleanup also makes the distinction between a SymbolicRegion and a
symbolic value that is a location much clearer. A SymbolicRegion
represents a chunk of symbolic memory, while a symbolic location is
just a "pointer" with different possible values. Without any specific
knowledge, a symbolic location resolves (i.e., via a dereference) to a
SymbolicRegion. In the future, when we do better alias reasoning, a
symbolic location can become an alias for another location, thus
merging the constraints on the referred SymbolicRegion with the other
region.
llvm-svn: 62769
Uncomment the define in Ownership.h to disable the smart pointers.
Disabled, the smart pointers no longer contain a pointer
to the action, and no longer have special destruction or
copying semantics. They are, compiler willing, raw
pointers or ActionResult equivalents.
llvm-svn: 62767
