Store this info inside the function summary generated for all analyzed
functions. This is useful for coverage stats and can be helpful for
analyzer state space search strategies.

llvm-svn: 153923

llvm-svn: 153922

Patch by Jack Carter. Testcase cleanup by me.

llvm-svn: 153921

wchar_t as distinct from int.

llvm-svn: 153920

This is supposed to succeed even with rdar://problem/11166975.

llvm-svn: 153919

I just noticed Jakob's examples of the proper application of
std::set... routines.

llvm-svn: 153918

property file/line rather than the @synthesize file/line. Avoids
some nasty confusing-ness with conflating the file from the scope
and the line from the original declaration. Use    the current scope
location as a separate parameter so that we can    match it up
better in the line table with the beginning of the scope.

Update a couple of testcases accordingly since I had to change
that we actually use the passed in location in EmitFunctionStart
and for the new metadata parameter and add a new testcase to
make sure we've got the right line numbers for synthesized
properties.

Part of rdar://11026482

llvm-svn: 153917

brace) so that we get more accurate line number information about the
declaration of a given function and the line where the function
first starts.

Part of rdar://11026482

llvm-svn: 153916

llvm-svn: 153915

Fixes to r153903.  Added missing explanation of behaviour when the VirtRegMap is NULL.  Also changed it in this case to just avoid updating the map, but live ranges or intervals will still get updated and created

llvm-svn: 153914

Fix another false positive in RegionStore involving doing loads from symbolic offsets.  We still don't
properly reason about such accesses, but we shouldn't emit bogus "uninitialized value" warnings
either.  Fixes <rdar://problem/11127008>.

llvm-svn: 153913

llvm-svn: 153912

llvm-svn: 153911

llvm-svn: 153910

llvm-svn: 153909

Fixed an issue where there were more than one way to get a CompileUnitSP created when using SymbolFileDWARF with SymbolFileDWARFDebugMap. This led to an assertion that would fire under certain conditions. Now there is only one way to create the compile unit and it will "do the right thing".

llvm-svn: 153908

llvm-svn: 153907

llvm-svn: 153906

llvm-svn: 153905

This is just the fallback tie-breaker ordering, the main allocation
order is still descending size.

Patch by Shamil Kurmangaleev!

llvm-svn: 153904

Refactored the LiveRangeEdit interface so that MachineFunction, TargetInstrInfo, MachineRegisterInfo, LiveIntervals, and VirtRegMap are all passed into the constructor and stored as members instead of passed in to each method.

llvm-svn: 153903

llvm-svn: 153902

Add predicates for checking whether targets have free FNEG and FABS operations, and prevent the DAGCombiner from turning them into bitwise operations if they do.

llvm-svn: 153901

Fix potential null dereference in the static analyzer when inlining a call that has already been inlined.  Unfortunately I have no test case.

llvm-svn: 153900

llvm-svn: 153899

Reduce static analyzer memory usage by about 4% by packing the ProgramPoing 'Kind' field into the spare bits of other fields.

llvm-svn: 153898

'copy assignment operator'.

llvm-svn: 153897

llvm-svn: 153896

llvm-svn: 153895

explicitly, deleted in all relevant cases, and explain why.

llvm-svn: 153894

Export the ability to see if a symbol is externally visible and also if the symbol was synthetically added to the symbol table (the symbol was not part of the symbol table itself but came from another section).

llvm-svn: 153893

operands. Make TryInstructionTransform return false to reflect this.
Fixes PR11861.

llvm-svn: 153892

rdar://problem/11167268

llvm-svn: 153891

llvm-svn: 153890

This patch allows llvm to recognize that a 64 bit object file is being produced
and that the subsequently generated ELF header has the correct information.

The test case checks for both big and little endian flavors.

Patch by Jack Carter.

llvm-svn: 153889

llvm-svn: 153888

The diagnostic message correctly informs the user that they have omitted the
'class' keyword, but neither suggests this insertion as a fixit, nor attempts
to recover as if they had provided the keyword.

This fixes the recovery, adds the fixit, and adds a separate diagnostic and
corresponding replacement fixit for cases where the user wrote 'struct' or
'typename' instead of 'class' (suggested by Richard Smith as a possible common
mistake).

I'm not sure the diagnostic message for either the original or new cases feel
very Clang-esque, so I'm open to suggestions there. The fixit hints make it
fairly easy to see what's required, though.

llvm-svn: 153887

llvm-svn: 153886

llvm-svn: 153885

not by canonical decl. This only matters for sizeof...(Pack) expressions; in
all other cases, we'd profile it as a type instead.

llvm-svn: 153884