Thanks to Bill Schmidt for finding this in review of r178480.

llvm-svn: 178521

variable in a C99 inline (but not static-inline or extern-inline)
function definition.

The standard doesn't actually say that this doesn't apply to
"extern inline" definitions, but that seems like a useful extension,
and it at least doesn't have the obvious flaw that a static
mutable variable in an externally-available definition does.

rdar://13535367

llvm-svn: 178520

Buffered means a later divide may be executed out-of-order while a
prior divide is sitting (buffered) in a reservation station.

You can tell it's not pipelined, because operations that use it
reserve it for more than one cycle:

def : WriteRes<WriteIDiv, [HWPort0, HWDivider]> {
  let Latency = 25;
  let ResourceCycles = [1, 10];
}

We don't currently distinguish between an unpipeline operation and one
that is split into multiple micro-ops requiring the same unit. Except
that the later may have NumMicroOps > 1 if they also consume
issue/dispatch resources.

llvm-svn: 178519

Refactor invalidateRegions to take SVals instead of Regions as input and teach RegionStore
about processing LazyCompoundVal as a top-level “escaping” value.

This addresses several false positives that get triggered by the NewDelete checker, but the
underlying issue is reproducible with other checkers as well (for example, MallocChecker).

llvm-svn: 178518

Make sure we do not generate line info for debugging-related frame setup.
Follow-up to r178361 / rdar://problem/12767564

llvm-svn: 178517

This is a heuristic to make up for the fact that the analyzer doesn't
model C++ containers very well. One example is modeling that
'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be
nice to model this explicitly, but for now it just results in a lot of
false positives.

The actual heuristic checks if the base type has a member named 'begin' or
'iterator'. If so, we treat the constructors and destructors of that type
as opaque, rather than inlining them.

This is intended to drastically reduce the number of false positives
reported with experimental destructor support turned on. We can tweak the
heuristic in the future, but we'd rather err on the side of false negatives
for now.

<rdar://problem/13497258>

llvm-svn: 178516

Certain properties of a function can determine ahead of time whether or not
the function is inlineable, such as its kind, its signature, or its
location. We can cache this value in the FunctionSummaries map to avoid
rechecking these static properties for every call.

Note that the analyzer may still decide not to inline a specific call to
a function because of the particular dynamic properties of the call along
the current path.

No intended functionality change.

llvm-svn: 178515

The summaries lasted for the lifetime of the map anyway; no reason to
include an extra allocation.

Also, use SmallBitVector instead of BitVector to track the visited basic
blocks -- most functions will have less than 64 basic blocks -- and
use bitfields for the other fields to reduce the size of the structure.

No functionality change.

llvm-svn: 178514

This is controlled by the 'suppress-c++-stdlib' analyzer-config flag.
It is currently off by default.

This is more suppression than we'd like to do, since obviously there can
be user-caused issues within 'std', but it gives us the option to wield
a large hammer to suppress false positives the user likely can't work
around.

llvm-svn: 178513

llvm-svn: 178512

to be correct.  No functionality or behavior change.

llvm-svn: 178511

llvm-svn: 178510

Note: although it is now possible to declare blocks
and call them inside the same expression, we do not
generate correct block descriptors so these blocks
cannot be passed to functions like dispatch_async.

<rdar://problem/12578656>

llvm-svn: 178509

llvm-svn: 178508

and Jordan's suggestion.  No functional change intendend.

llvm-svn: 178507

Revision 177141 caused a regression in all but
mips64 little endian. That is because none of the
other Mips targets had test cases checking the 
contents of the .eh_frame section. This patch fixes
both the llvm code and adds an assembler test case 
to include the current 4 flavors.

The test cases unfortunately rely on llvm-objdump. A
preferable method would be to use a pretty printer output
such as what readelf -wf <elf_file> would give.

I also changed the name of the test case to correct a typo.

llvm-svn: 178506

llvm-svn: 178505

llvm-svn: 178504

llvm-svn: 178503

specifier for an enumeration. Also fix a crash-on-invalid if a non-dependent
name specifier is used to declare an enum template.

llvm-svn: 178502

[arcmt] Copy the diagnostics so we don't have to worry about invaliding iterators from the diagnostic list.

Should fix http://llvm.org/PR15500

llvm-svn: 178500

v2:
  - Add a test case

v3:
  - Use the -### clang option in the tests

llvm-svn: 178499

llvm-svn: 178498

Also add a test for PR15637.

llvm-svn: 178497

member inside a class template) when loading a PCH file or module.

llvm-svn: 178496

llvm-svn: 178495

Previously UseNullptr matched separately implicit and explicit casts to nullptr,
now it matches casts that either are implict casts to nullptr or have an
implicit cast to nullptr within.

Also fixes PR15572 since the same macro replacement logic is applied to implicit
and explicit casts.

llvm-svn: 178494

- process in 'unloaded' state was (incorrectly) considered to be alive by POSIX plugin
- above caused a regression in TestProcessLaunch cases

llvm-svn: 178493

llvm-svn: 178492

- Check that process attach succeeded before attempting to WaitForProcessToStop (observed to cause hangs on Linux)
- Update comment in TestHelloWorld case -- attaching by name still broken

llvm-svn: 178491

  when we actually end a lexical block.
* Added new test for line table / block cleanup.
* Follow-up to r177819 / rdar://problem/13115369

llvm-svn: 178490

llvm-svn: 178489

visible.  There's a lot of potential badness in how we're modelling
these things, but getting this much correct is reasonably easy.

rdar://13535367

llvm-svn: 178488

    
Updated docs and tests.

llvm-svn: 178487

llvm-svn: 178486

Loop convert's variable name aliasing may cause issues if the variable is
declared as a value (copy). The converted loop will declare the variable as a
reference which may inadvertently cause modifications to the container if it
were used and modified as a temporary copy.

This is fixed by preserving the reference or value qualifiers of the aliased
variable. That is, if the variable was declared as a value the loop variable
will also be declared as a value and similarly for references.

Fixes: PR15600
Author: Jack Yang <jack.yang@intel.com>
llvm-svn: 178485

llvm-svn: 178484

We would also like to merge sequences that involve a variable index like in the
example below.

    int index = *idx++
    int i0 = c[index+0];
    int i1 = c[index+1];
    b[0] = i0;
    b[1] = i1;

By extending the parsing of the base pointer to handle dags that contain a
base, index, and offset we can handle examples like the one above.

The dag for the code above will look something like:

 (load (i64 add (i64 copyfromreg %c)
                (i64 signextend (i8 load %index))))

 (load (i64 add (i64 copyfromreg %c)
                (i64 signextend (i32 add (i32 signextend (i8 load %index))
                                         (i32 1)))))

The code that parses the tree ignores the intermediate sign extensions. However,
if there is a sign extension it needs to be on all indexes.

 (load (i64 add (i64 copyfromreg %c)
                (i64 signextend (add (i8 load %index)
                                     (i8 1))))
 vs

 (load (i64 add (i64 copyfromreg %c)
                (i64 signextend (i32 add (i32 signextend (i8 load %index))
                                         (i32 1)))))
radar://13536387

llvm-svn: 178483

To hook it up to individual test cases:
- define GetLongOptions() in your test case class to return something other than NULL (hopefully an array of options :-)
- implement ParseOption() to check for the short option char and do the right thing - return true at the end if you want more options to come your way or false if you don’t
- make sure that your Setup() call takes int& and char**& so that optind post-processing can happen - and call TestCase::Setup from your setup

llvm-svn: 178482

llvm-svn: 178481