Pass TargetOptions to HexagonTargetMachine constructor by reference to match other targets and the base class.

llvm-svn: 152979

llvm-svn: 152978

the availability of the enumeration type itself. Fixes
<rdar://problem/10996386>.

llvm-svn: 152977

[analyzer] Don't claim an object was returned with +1 retain count before counting autoreleases. Fixes PR10376.

(Also, 80-column violations.)

llvm-svn: 152976

llvm-svn: 152975

Remove unused entitlements plist from debugserver.

llvm-svn: 152973

llvm-svn: 152972

Pointing users to a new example of synthetic children provider en lieu of the old StdVector example which was removed earlier today

llvm-svn: 152971

llvm-svn: 152970

(The plist output does not match the one we expect, specifically we do
not detect that the interesting symbol is returned by a call.)

llvm-svn: 152969

Fix crash on invalid code.  I've tried to produce a reduced test case, but when I do the specific crash is hidden.  Fixes <rdar://problem/11063594>.

llvm-svn: 152968

 evaluated to '1' when the argument list was empty (should be '0').

rdar://11057257

llvm-svn: 152967

llvm-svn: 152966

ARM assembly syntax in LLVM.  This allows LLDB to
build with the latest Clang.

llvm-svn: 152965

Do not display the standard "Returning from 'foo'", when a stack hint is
available.

llvm-svn: 152964

llvm-svn: 152963

The symbol-aware stack hint combines the checker-provided message
with the information about how the symbol was passed to the callee: as
a parameter or a return value.

For malloc, the generated messages look like this :
"Returning from 'foo'; released memory via 1st parameter"
"Returning from 'foo'; allocated memory via 1st parameter"
"Returning from 'foo'; allocated memory returned"
"Returning from 'foo'; reallocation of 1st parameter failed"


(We are yet to handle cases when the symbol is a field in a struct or
an array element.)

llvm-svn: 152962

llvm-svn: 152961

number of steps in the work list.

llvm-svn: 152960

fast-isel before emitting code. If the program bails after code was emitted,
then it could lead to the stack being adjusted more than once (two
CALLSEQ_BEGINs emitted) but being adjuste back only once after the call. This
leads to general badness and gnashing of teeth.
<rdar://problem/11050630>

llvm-svn: 152959

llvm-svn: 152958

llvm-svn: 152957

% is a common character in IR so we'd crash on almost any malformed IR. The
diagnostic formatter expects a formatting directive when it sees an unescaped %.

llvm-svn: 152956

llvm-svn: 152955

rdar://11065671

llvm-svn: 152954

llvm-svn: 152953

Export the APIs submitted by Dawn to the Python bindings.  Add a simple test case for the SBModule.compile_unit_iter() API.

llvm-svn: 152952

store to 1. This allows code-gen to select a more appropriate alignment. If left
to zero, an alignment greater than the alignment of the pointer may be selected,
causing code-gen to use instructions which require an alignment greater than the
pointer guarantees.
<rdar://problem/11043589>

llvm-svn: 152951

llvm-svn: 152950

// rdar://11063663

llvm-svn: 152949

llvm-svn: 152948

llvm-svn: 152946

llvm-svn: 152945

It's not a good style idea, as the registers will be laid down in memory in
numerical order, not the order they're in the list, but it's legal. vldm/vstm
are stricter.

rdar://11064740

llvm-svn: 152943

GetSupportFileAtIndex(), GetNumSupportFiles(), FindSupportFileIndex():
   Add API support for getting the list of files in a compilation unit.
GetNumCompileUnits(), GetCompileUnitAtIndex():
   Add API support for retrieving the compilation units in a module.

llvm-svn: 152942

llvm-svn: 152941

For "int i = NULL;" we would produce:

null.cpp:5:11: warning: implicit conversion of NULL constant to integer [-Wconversion]
  int i = NULL;
      ~   ^~~~
null.cpp:1:14: note: expanded from macro 'NULL'
\#define NULL __null
              ^~~~~~

But we really shouldn't trace that macro expansion back into the header, yet we
still want macro back traces for code like this:

\#define FOO NULL
int i = FOO;

or

\#define FOO int i = NULL;
FOO

While providing appropriate tagging at different levels of the expansion, etc.

The included test case exercises these cases & does some basic validation (to
ensure we don't have macro expansion notes where we shouldn't, and do where we
should) - but doesn't go as far as to validate the source location/ranges
used in those notes and warnings.

llvm-svn: 152940

llvm-svn: 152939

This fixes g++.dg/parse/friend5.C.

llvm-svn: 152938

After r150615, which tablegens the group of a diagnostic as an index into the *.inc file, all diagnostic *.inc
files depend on all other diagnostic *.td files, because a diagnostic group can be introduced at any of the diagnostic
*.td files.

llvm-svn: 152937