of LSR. This makes the AddUsersIfInteresting phase of LSR a pure
analysis instead of a phase that potentially does CFG modifications.
The conditions where this code would actually perform a split are
rare, and in the cases where it actually would do a split the split
is usually undone by CodeGenPrepare, and in cases where splits
actually survive into codegen, they appear to hurt more often than
they help.
llvm-svn: 70625
into the left-hand side of an assignment expression. This completes
most of PR3500; the only remaining part is to deal with the
GCC-specific implementation-defined behavior for "unsigned long" (and
other) bit-fields.
llvm-svn: 70623
expressions not yet properly handled by the CFGBuilder. This failure resulted in
a null CFGBlock* being used in rare cases (causing a crash).
llvm-svn: 70612
might be wider than we're supposed to print. In this case, we try to
select the "important" subregion of the source line, which contains
everything that we want to show (e.g., with underlining and the caret
itself) and tries to also contain some of the context.
From the fantastically long line in the test case, we get an error
message that slices down to this:
message-length.c:18:120: warning: comparison of distinct pointer types
('int *' and 'float *')
a_func_to_call(ip == FloatPointer, ip[ALongIndexName],
~~ ^ ~~~~~~~~~~~~
There are a bunch of gee-it-sounds-good heuristics in here, which seem
to do well on the various simple tests I've thrown at it. However,
we're going to need to look at a bunch more diagnostics to tweak these
heuristics.
This is the second part of <rdar://problem/6711348>. Almost there!
llvm-svn: 70597
Also, put a line of whitespace between the diagnostic and the source
code/caret line when the start of the actual source code text lines up
(or nearly lines up) with the most recent line of the diagnostic. For
example, here it's okay for the last line of the diagnostic to be
(vertically) next to the source line, because there is horizontal
whitespace to separate them:
decl-expr-ambiguity.cpp:12:16: error: function-style cast to a builtin
type can only take one argument
typeof(int)(a,5)<<a;
However, here is a case where we need the vertical separation (since
there is no horizontal separation):
message-length.c:10:46: warning: incompatible pointer types initializing 'void
(int, float, char, float)', expected 'int (*)(int, float, short,
float)'
int (*fp1)(int, float, short, float) = f;
This is part one of <rdar://problem/6711348>.
llvm-svn: 70578
- Don't layer TypedViewRegions on top of any region except
SymbolicRegions and AllocaRegions. This follows from my offline
discussion within Zhongxing about how TypedViewRegions really only
represent memory getting re-appropriated for a new purpose.
Fallout from this change:
- Move test case from xfail_rdar_6440393.m to misc-ps-64.m
(it now passes).
- test/Analysis/fields.c now fails for region store (crash).
Marking XFAIL.
- test/Analysis/rdar-6441136-region.c now fails (only runs with region store).
Marking XFAIL.
Diagnosis: The analyzer now correctly identifies an early out-of-bounds memory
access then the one flagged:
rdar-6541136-region.c:17:3: warning: Load or store into an out-of-bound memory position.
*p = 1;
^~
Changing the line:
char *p = (void*) &wonky[1];
to
char *p = (void*) &wonky[0];
(which should delay the buffer overrun) causes region store to crash, probably
because it expects a TypedViewRegion.
- test/Analysis/casts.c (region store) now fails (crash).
Marking XFAIL.
llvm-svn: 70565
target hooks canLosslesslyBitCastTo and isTruncateFree. This allows
targets to avoid worrying about handling all combinations of integer
and pointer types.
llvm-svn: 70555
artificial "ptrtoint", as it tends to clutter up complicated
expressions. The cast operators now print both source and
destination types, which is usually sufficient.
llvm-svn: 70554
Daniel Dunbar