| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 164971
|
|
|
|
|
|
|
| |
32bit and 64bit version of modern translator.
// rdar://12189793
llvm-svn: 164970
|
|
|
|
| |
llvm-svn: 164969
|
|
|
|
|
|
| |
in core constant expressions, despite not being a literal type.
llvm-svn: 164968
|
|
|
|
|
|
|
| |
representation. Fix crash if it appears in the return type of a member function
definition.
llvm-svn: 164967
|
|
|
|
| |
llvm-svn: 164966
|
|
|
|
| |
llvm-svn: 164965
|
|
|
|
| |
llvm-svn: 164964
|
|
|
|
| |
llvm-svn: 164961
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By analogy with C structs, this seems to be legal, if probably discouraged.
It's only if the ivar is read from or written to that there's a problem.
Running a program that gets the "address" of an instance variable does in
fact return the offset when the base "object" is nil.
This isn't a full revert because r164442 includes some diagnostic tweaks
as well; those have been kept.
This partially reverts r164442 / 08965091770c9b276c238bac2f716eaa4da2dca4.
llvm-svn: 164960
|
|
|
|
|
|
|
|
| |
This seems to be legal according to C11 6.5.3.2.
No functionality change.
llvm-svn: 164959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an lvalue."
The original intent of this commit was to catch potential null dereferences
early, but it breaks the common "home-grown offsetof" idiom (PR13927):
(((struct Foo *)0)->member - ((struct foo *)0))
As it turns out, this appears to be legal in C, per a footnote in
C11 6.5.3.2: "Thus, &*E is equivalent to E (even if E is a null pointer)".
In C++ this issue is still open:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232
We'll just have to make sure we have good path notes in the future.
This reverts r164441 / 9be016dcd1ca3986873a7b66bd4bc027309ceb59.
llvm-svn: 164958
|
|
|
|
|
|
| |
care of comments by Dimitri and Doug.
llvm-svn: 164957
|
|
|
|
|
|
|
|
|
| |
The Apple buildbots have been modified not to pass --target,
so they shouldn't choke on a default program prefix anymore.
Patch by Rick Foos!
llvm-svn: 164956
|
|
|
|
|
|
|
|
| |
string in the config table so that it can be dumped as part of the
config dumper. Add a test to show that these options are sticking
and can be cross-checked using FileCheck.
llvm-svn: 164954
|
|
|
|
|
|
|
| |
The format of this output is a WIP; largely I'm bringing it up now
for regression testing. We can evolve the output format over time.
llvm-svn: 164953
|
|
|
|
|
|
|
|
|
|
|
| |
correctly."
This is related to but not blocked by <rdar://problem/12137950>
("Return-by-value structs do not have associated regions")
This reverts r164875 / 3278d41e17749dbedb204a81ef373499f10251d7.
llvm-svn: 164952
|
|
|
|
|
|
|
|
|
|
|
| |
-Allow Sema to do more processing on the initial Expr before checking it.
-Remove the special conditions in HandleExpr()
-Move the code so that only one call site is needed.
-Removed the function from Sema and only call it locally.
-Warn on potentially evaluated reference variables, not just casts to r-values.
-Update tests.
llvm-svn: 164951
|
|
|
|
|
|
| |
to accessing a shared pointer without first checking for NULL
llvm-svn: 164950
|
|
|
|
| |
llvm-svn: 164949
|
|
|
|
|
|
| |
calling conventions.
llvm-svn: 164948
|
|
|
|
|
|
|
|
|
| |
It is possible and valid to have a state manager and associated objects
without having a SubEngine or checkers.
Patch by Olaf Krzikalla!
llvm-svn: 164947
|
|
|
|
|
|
|
|
|
| |
- Update maximal stack alignment when stack arguments are prepared before a
call.
- Test cases are enhanced to show it's not a Win32 specific issue but a generic
one.
llvm-svn: 164946
|
|
|
|
|
|
|
| |
Reduces runtime of i386-large-relocations.s by 10x in Release builds, even more
in Debug+Asserts builds.
llvm-svn: 164945
|
|
|
|
|
|
| |
"#include <initializer_list>" is unavailable for whatever reason.
llvm-svn: 164944
|
|
|
|
|
|
|
| |
Patch by Gábor Horváth.
Review: http://llvm-reviews.chandlerc.com/D46
llvm-svn: 164943
|
|
|
|
| |
llvm-svn: 164940
|
|
|
|
|
|
| |
is the second time I've moved this comment around...)
llvm-svn: 164939
|
|
|
|
| |
llvm-svn: 164938
|
|
|
|
|
|
|
|
|
|
| |
alignment requirements of the new alloca. As one consequence which was
reported as a bug by Duncan, we overaligned memcpy calls to ranges of
allocas after they were rewritten to types with lower alignment
requirements. Other consquences are possible, but I don't have any test
cases for them.
llvm-svn: 164937
|
|
|
|
| |
llvm-svn: 164935
|
|
|
|
|
|
|
|
| |
value.
Fixes PR13985.
llvm-svn: 164934
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
could probably be factored still further to hoist this logic into
a generic helper, but currently I don't have particularly clean ideas
about how to handle that.
This at least allows us to drop custom load rewriting from the
speculation logic, which in turn allows the existing load rewriting
logic to fire. In theory, this could enable vector promotion or other
tricks after speculation occurs, but I've not dug into such issues. This
is primarily just cleaning up the factoring of the code and the
resulting logic.
llvm-svn: 164933
|
|
|
|
|
|
|
|
| |
Lookup can nevertheless find them due to the serialized lookup table.
For instance when reading a template decl's templatedDecl, it will search for existing decls that it could be a redeclaration of, and find the half-read template decl.
Thus there is no point in asserting the names of decls.
llvm-svn: 164932
|
|
|
|
|
|
| |
Don't require specializations (of existing and read template) to be unique.
llvm-svn: 164931
|
|
|
|
|
|
|
| |
Also move one of them from grep to FileCheck.
Patch from Joey Gouly <joey.gouly@arm.com>!
llvm-svn: 164929
|
|
|
|
| |
llvm-svn: 164928
|
|
|
|
|
|
|
|
|
| |
specialization was written, which is non-canonical at the time of reading: force the reading of the ClassTemplateDecl if it was written.
The easiest way out is to store whether the decl was canonical at the time of writing.
Add test.
llvm-svn: 164927
|
|
|
|
|
|
| |
into a lookup table.
llvm-svn: 164926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a pair of instructions, one for the used pointer and the second for the
user. This simplifies the representation and also makes it more dense.
This was noticed because of the miscompile in PR13926. In that case, we
were running up against a fundamental "bad idea" in the speculation of
PHI and select instructions: the speculation and rewriting are
interleaved, which requires phi speculation to also perform load
rewriting! This is bad, and causes us to miss opportunities to do (for
example) vector rewriting only exposed after PHI speculation, etc etc.
It also, in the old system, required us to insert *new* load uses into
the current partition's use list, which would then be ignored during
rewriting because we had already extracted an end iterator for the use
list. The appending behavior (and much of the other oddities) stem from
the strange de-duplication strategy in the PartitionUse builder.
Amusingly, all this went without notice for so long because it could
only be triggered by having *different* GEPs into the same partition of
the same alloca, where both different GEPs were operands of a single
PHI, and where the GEP which was not encountered first also had multiple
uses within that same PHI node... Hence the insane steps required to
reproduce.
So, step one in fixing this fundamental bad idea is to make the
PartitionUse actually contain a Use*, and to make the builder do proper
deduplication instead of funky de-duplication. This is enough to remove
the appending behavior, and fix the miscompile in PR13926, but there is
more work to be done here. Subsequent commits will lift the speculation
into its own visitor. It'll be a useful step toward potentially
extracting all of the speculation logic into a generic utility
transform.
The existing PHI test case for repeated operands has been made more
extreme to catch even these issues. This test case, run through the old
pass, will exactly reproduce the miscompile from PR13926. ;] We were so
close here!
llvm-svn: 164925
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 164924
|
|
|
|
|
|
|
|
| |
(switches), avoid it if possible.
No functionality change.
llvm-svn: 164923
|
|
|
|
| |
llvm-svn: 164922
|
|
|
|
|
|
| |
bad. Fonts already have appropriate tracking built-in.
llvm-svn: 164921
|
|
|
|
| |
llvm-svn: 164920
|
|
|
|
|
|
| |
EVT and add llvm_unreachable to the switches. Helps it compile to dramatically better code.
llvm-svn: 164919
|
|
|
|
|
|
| |
Fun fact: The CBE learned how to deal with this situation before it was removed.
llvm-svn: 164918
|
|
|
|
|
|
|
|
|
|
| |
or move assign operator.
This fixes a regression from r162254, the optimizer has problems reasoning
about the smaller memcpy as it's often not safe to widen a store but making it
smaller is.
llvm-svn: 164917
|
|
|
|
|
|
| |
building clang only.
llvm-svn: 164916
|
|
|
|
| |
llvm-svn: 164915
|