r183584 tries to derive some info from the code *AFTER* a call and apply
these derived info to the code *BEFORE* the call, which is not always safe
as the call in question may never return, and in this case, the derived
info is invalid.
  
  Thank Duncan for pointing out this potential bug.

rdar://14073661 

llvm-svn: 183606

sys::IdentifyFileType is already conscious of the length, and
object_error::invalid_file_type is returned below anyway if
sys::IdentifyFileType doesn't recognize the file.

llvm-svn: 183605

llvm-svn: 183604

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