llvm-svn: 183603

llvm-svn: 183602

llvm-svn: 183601

Based on feedback from Jordan.

llvm-svn: 183600

We drew the diagnostic edges to wrong statements in cases the note was on a macro.
The fix is simple, but seems to work just fine for a whole bunch of test cases (plist-macros.cpp).

Also, removes an unnecessary edge in edges-new.mm, when function signature starts with a macro.

llvm-svn: 183599

llvm-svn: 183598

Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.

rdar://problem/14024005

llvm-svn: 183597

destination operands of an instruction.

No functionality changes.

llvm-svn: 183596

instantiation issue with non-standard type.

Add a backend option to warn on a given stack size limit.
Option: -mllvm -warn-stack-size=<limit>
Output (if limit is exceeded):
warning: Stack size limit exceeded (<actual size>) in <functionName>.

The longer term plan is to hook that to a clang warning.
PR:4072
<rdar://problem/13987214>.

llvm-svn: 183595

created through binding a reference-to-array to an initializer list.

llvm-svn: 183594

This is using a hint from AMD APP OpenCL Programming Guide with
empirically tweaked parameters.
I used Unigine Heaven 3.0 to determine best parameters on my system
(i7 2600/Radeon 6950/Kernel 3.9.4) the benchmark :
it went from 38.8 average fps to 39.6, which is ~3% gain.
(Lightmark 2008.2 gain is much more marginal: from 537 to 539)

There is no lit test provided as the parameter were determined
empirically and it it would be nearly impossiblet to find a test
program that check for optimal behavior.

llvm-svn: 183593

llvm-svn: 183592

sure to do this always, this matches the behavior for the gcc driver.

Fixes PR16251.

Based on a patch by Qiao Yang.

llvm-svn: 183591

llvm-svn: 183590

llvm-svn: 183589

Loosen r178109 even further, to assume that all redefined macros in system headers and system modules are equivalent.

Fixes <rdar://problem/14025673>.

llvm-svn: 183588

llvm-svn: 183587

llvm-svn: 183586

llvm-svn: 183585

  The MemCpyOpt pass is capable of optimizing:
      callee(&S); copy N bytes from S to D.
    into:
      callee(&D);
subject to some legality constraints. 

  Assertion is triggered when the compiler tries to evalute "sizeof(typeof(D))",
while D is an opaque-typed, 'sret' formal argument of function being compiled.
i.e. the signature of the func being compiled is something like this:
  T caller(...,%opaque* noalias nocapture sret %D, ...)

  The fix is that when come across such situation, instead of calling some
utility functions to get the size of D's type (which will crash), we simply
assume D has at least N bytes as implified by the copy-instruction.

rdar://14073661 

llvm-svn: 183584

llvm-svn: 183583

- factor the name construction part out from constructSetterName
- rename constructSetterName to the more appropriate constructSetterSelector

no functionality change intended.
rdar://problem/14035789

llvm-svn: 183582

On PPC32, [su]div,rem on i64 types are transformed into runtime library
function calls. As a result, they are not allowed in counter-based loops (the
counter-loops verification pass caught this error; this change fixes PR16169).

llvm-svn: 183581

llvm-svn: 183580

llvm-svn: 183579

llvm-svn: 183578

EINTR.  That means the user was trying to interrupt us, and we should just stop instead.

<rdar://problem/13184758>

llvm-svn: 183577

We've got the type right, which has broken these tests - but now we need to get the location information correct that the type was papering over

llvm-svn: 183576

The approach r183084 took was wrong, back it out.

llvm-svn: 183575

llvm-svn: 183574

This fixes a recent regression (r183338). Stripped elf files (like installed
crtn.o for example), are not required to have a symbol table. Handle that
correctly.

llvm-svn: 183573

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183572

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183571

llvm-svn: 183570

llvm-svn: 183569

We weren't computing structure size correctly and we were relying on
the original alloca instruction to compute the offset, which isn't
always reliable.

Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183568

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183567

This should simplify the subtarget definitions and make it easier to
add new ones.

Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183566

the internals of TargetMachine could change.

No functionality change intended.

llvm-svn: 183565

llvm-svn: 183564