deleting it.  This will let ScalarEvolution be more complete about
updating its records.

llvm-svn: 70632

llvm-svn: 70630

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

llvm-svn: 70620

llvm-svn: 70619

the runtime version number onto it, so that the debugger knows it's an objc
interface, not a C struct.  rdar://6848435

llvm-svn: 70618

llvm-svn: 70617

several other fixes coming.

llvm-svn: 70616

llvm-svn: 70615

llvm-svn: 70614

Fix bitfield promotions in several more cases. We don't seem to work hard enough at determining whether an expression is a bitfield or not, yet.

llvm-svn: 70613

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

going to a terminal, word-wrap to the length of the terminal.

llvm-svn: 70611

"Invalid primitive type" on input containing the x86_fp80 type.'
Patch by Collin Winter!

llvm-svn: 70610

helps some problems on win32 platforms (PR4119)

llvm-svn: 70603

llvm-svn: 70602

llvm-svn: 70601

llvm-svn: 70600

llvm-svn: 70599

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

llvm-svn: 70595

and ps documentation.

llvm-svn: 70589

llvm-svn: 70586

GRCoreEngine. This tends to result in shorter paths for pathological cases.

llvm-svn: 70585

llvm-svn: 70584

"Construction" makes it sound like a pass that might
modify the CFG to construct natural loops.

llvm-svn: 70580

llvm-svn: 70579

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

llvm-svn: 70572

llvm-svn: 70571

llvm-svn: 70570

llvm-svn: 70569

class/protocol and implementation which could be
an imm. implementation or down in the inheritance
hierarchy.

llvm-svn: 70568

llvm-svn: 70567

llvm-svn: 70566

- 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

llvm-svn: 70564

llvm-svn: 70563

llvm-svn: 70562