llvm-svn: 134831

expecting so much concentrated oddity on what seemed like a
trivial feature.  Thanks to François Pichet for doing the
MSVC legwork here.

llvm-svn: 134813

llvm-svn: 134785

  - Emit default-initialization of arrays that were partially initialized
    with initializer lists with a loop, rather than emitting the default
    initializer N times;
  - support destroying VLAs of non-trivial type, although this is not
    yet exposed to users; and
  - support the partial destruction of arrays initialized with
    initializer lists when an initializer throws an exception.

llvm-svn: 134784

Note that because we don't usually touch the MMX registers anyway, all -mno-mmx needs to do is tweak the x86-32 calling convention a little for vectors that look like MMX vectors, and prevent the definition of __MMX__.

clang doesn't actually stop the user from using MMX inline asm operands or MMX builtins in -mno-mmx mode; as a QOI issue, it would be nice to diagnose, but I doubt it really matters much.

<rdar://problem/9694837>

llvm-svn: 134770

llvm-svn: 134765

llvm-svn: 134761

llvm-svn: 134754

llvm-svn: 134743

Found by valgrind.

llvm-svn: 134733

llvm-svn: 134731

Fix up dependency file name printing to more closely match that of gcc, including fixing a nasty recent regression that could make us print "/foo.h" with a command-line including "-I ./".

rdar://problem/9734352

llvm-svn: 134728

object to a __weak object type. // rdar://9732636

llvm-svn: 134706

lvalue/xvalue/rvalue, rather than just (incorrectly) assuming it's an
lvalue. Fixes PR10285 / <rdar://problem/9743926>.

llvm-svn: 134700

Previously, despite the names 'enqueue' and 'dequeue', it behaved as
a stack and visited blocks in a LIFO fashion. This interacts badly with
extremely broad CFGs *inside* of a loop (such as a large switch inside
a state machine) where every block updates a different variable.

When encountering such a CFG, the checker visited blocks in essentially
a "depth first" order due to the stack-like behavior of the work list.
Combined with each block updating a different variable, the saturation
logic of the checker caused it to re-traverse blocks [1,N-1] of the
broad CFG inside the loop after traversing block N. These re-traversals
were to propagate the variable values derived from block N. Assuming
approximately the same number of variables as inner blocks exist, the
end result is O(N^2) updates. By making this a queue, we also make the
traversal essentially "breadth-first" across each of the N inner blocks
of the loop. Then all of this state is propagated around to all N inner
blocks of the loop. The result is O(N) updates.

The truth is in the numbers:
Before, gcc.c:   96409 block visits  (max: 61546,   avg: 591)
After,  gcc.c:   69958 block visits  (max: 33090,   avg: 429)
Before, PR10183: 2540494 block vists (max: 2536495, avg: 37360)
After,  PR10183: 137803 block visits (max: 134406,  avg: 2026)

The nearly 20x reduction in work for PR10183 corresponds to a roughly
100x speedup in compile time.

I've tested it on all the code I can get my hands on, and I've seen no
slowdowns due to this change. Where I've collected stats, the ammount of
work done is on average less. I'll also commit shortly some synthetic
test cases useful in analyzing the performance of CFG-based warnings.

Submitting this based on Doug's feedback that post-commit review should
be good. Ted, please review! Hopefully this helps compile times until
then.

llvm-svn: 134697

change.

Previously clang was passing the following feature strings to the ARM backend
when CPU is cortex-a8: +neon,-vfp2,-vfp3

This used to work because -vfp2,-vfp3 had no effect after +neon. Now that the
features are controlled by individual bits (with implied hierarchy), the net
effect is all three features will be turned off.

llvm-svn: 134691

- fix a comment.
- Remove an unnecessary { } block.

llvm-svn: 134690

confusing indentations I've seen recently... Just noticed these while
making a change elsewhere.

No functionality changed.

llvm-svn: 134685

Original patch by John Freeman, some style tweaks by me.

llvm-svn: 134683

llvm-svn: 134675

argument expansion to use the macro argument source locations as well.
Add a few tests to exercise this. There is still a bit more work needed
here though.

llvm-svn: 134674

instantiation and improve diagnostics which are stem from macro
arguments to trace the argument itself back through the layers of macro
expansion.

This requires some tricky handling of the source locations, as the
argument appears to be expanded in the opposite direction from the
surrounding macro. This patch provides helper routines that encapsulate
the logic and explain the reasoning behind how we step through macros
during diagnostic printing.

This fixes the rest of the test cases originially in PR9279, and later
split out into PR10214 and PR10215.

There is still some more work we can do here to improve the macro
backtrace, but those will follow as separate patches.

llvm-svn: 134660

object to a __weak object/type. // rdar://9732636.
One item is yet todo.

llvm-svn: 134655

Fixes PR10299 and rdar://9740322

llvm-svn: 134654

Remove BoostCon-specific code from Clang.  FWIW, I'm a fan of things like this living in a separate branch.

llvm-svn: 134649

Move SourceManager::isAt[Start/End]OfMacroInstantiation functions to the Lexer, since they depend on it now.

llvm-svn: 134644

the normal case.

Before, for this:

$ cat t.c
int test(int x) { return x * 2; }

We would get this:

   addl  %edi, %edi
   jno   LBB0_2
## BB#1:                                ## %overflow
   ud2
LBB0_2:                                 ## %nooverflow
   movl    %edi, %eax
   popq    %rbp
   ret

Now we get this:

   addl   %edi, %edi
   jo     LBB0_2
## BB#1:                                ## %nooverflow
   movl                                 %edi, %eax
   popq                                 %rbp
   ret
LBB0_2:                                 ## %overflow
   ud2

<rdar://problem/8283919>

llvm-svn: 134642

so roll it out.

llvm-svn: 134638

function. Fixes PR10233!

llvm-svn: 134634

object to a __weak object/type. // rdar://9732636.
This is objc side of things. objc++ side tbd.

llvm-svn: 134624

llvm-svn: 134621

llvm-svn: 134619

clang_codeCompleteGetContexts(), that provides the client with
information about the context in which code completion has occurred
and what kinds of entities make sense as completions at that
point. Patch by Connor Wakamo!

llvm-svn: 134615

If we're using the pure non-fragile ABI, then skip some of the contortions required to support the transitional ABI.

llvm-svn: 134612

Set a flag to tell the runtime when we're compiling in ARC mode and use the pure-nonfragile ABI for both ARC and GC mode.

llvm-svn: 134611

where we have an immediate need of a retained value.

As an exception, don't do this when the call is made as the immediate
operand of a __bridge retain.  This is more in the way of a workaround
than an actual guarantee, so it's acceptable to be brittle here.

rdar://problem/9504800

llvm-svn: 134605

llvm-svn: 134591

llvm-svn: 134589

e.g.

#define M(x) A x B
M(##) // should expand to 'A ## B', not 'AB'

llvm-svn: 134588

When a macro instantiation occurs, reserve a SLocEntry chunk with length the
full length of the macro definition source. Set the spelling location of this chunk
to point to the start of the macro definition and any tokens that are lexed directly
from the macro definition will get a location from this chunk with the appropriate offset.

For any tokens that come from argument expansion, '##' paste operator, etc. have their
instantiation location point at the appropriate place in the instantiated macro definition
(the argument identifier and the '##' token respectively).
This improves macro instantiation diagnostics:

Before:

t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
        ^~~~
t.c:5:11: note: instantiated from:
int y = M(/);
          ^

After:

t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
        ^~~~
t.c:3:20: note: instantiated from:
\#define M(op) (foo op 3);
                ~~~ ^  ~
t.c:5:11: note: instantiated from:
int y = M(/);
          ^

The memory savings for a candidate boost library that abuses the preprocessor are:

- 32% less SLocEntries (37M -> 25M)
- 30% reduction in PCH file size (900M -> 635M)
- 50% reduction in memory usage for the SLocEntry table (1.6G -> 800M)

llvm-svn: 134587