llvm-svn: 168340

them in order to parse the rest of the file.

llvm-svn: 168327

getUnderlyingDecl()) so that derivatives of
CorrectionCandidateCallback::ValidateCandidate(...) don't have to worry
about being thrown by UsingDecls and such.

llvm-svn: 168317

According to Android ABI, we have to link with
libdl.so, if we are linking with non-static libgcc.

Besides, this also fixes MIPS link error of
undefined references to `_Unwind_Find_FDE' and
`dl_iterate_phdr'.

llvm-svn: 168310

The dynamic linker of Android does not support .ctors/.dtors.
We should emit .init_array and .fini_array regardless the
gcc version.

NOTE: This patch does not affect the ARM backend, because
it is required to generate .init_array and .fini_array
for program targeting ARM AAPCS and AEABI.

llvm-svn: 168309

There were numerous issues here that were all entangled, and so I've
tried to do a general simplification of the logic.
1) The logic was mimicing actual GCC bugs, rather than "features". These
   have been fixed in trunk GCC, and this fixes Clang as well. Notably,
   the logic was always intended to be last-match-wins like any other
   flag.
2) The logic for handling '-mdynamic-no-pic' was preposterously unclear.
   It also allowed the use of this flag on non-Darwin platforms where it
   has no actual meaning. Now this option is handled directly based on
   tests of how llvm-gcc behaves, and it is only supported on Darwin.
3) The APIs for the Driver's ToolChains had the implementation ugliness
   of dynamic-no-pic leaking through them. They also had the
   implementation details of the LLVM relocation model flag names
   leaking through.
4) The actual results of passing these flags was incorrect on Darwin in
   many cases. For example, Darwin *always* uses PIC level 2 if it uses
   in PIC level, and Darwin *always* uses PIC on 64-bit regardless of
   the flags specified, including -fPIE. Darwin never compiles in PIE
   mode, but it can *link* in PIE mode.
5) Also, PIC was not always being enabled even when PIE was. This isn't
   a supported mode at all and may have caused some fallout in builds
   with complex PIC and PIE interactions.

The result is (I hope) cleaner and clearer for readers. I've also left
comments and tests about some of the truly strage behavior that is
observed on Darwin platforms. We have no real testing of Windows
platforms and PIC, but I don't have the tools handy to figure that out.
Hopefully others can beef up our testing here.

Unfortunately, I can't test this for every platform. =/ If folks have
dependencies on these flags that aren't covered by tests, they may
break. I've audited and ensured that all the changes in behavior of the
existing tests are intentional and good. In particular I've tried to
make sure the Darwin behavior (which is more suprising than the Linux
behavior) also matches that of 'gcc' on my mac.

llvm-svn: 168297

llvm-svn: 168293

We actually used to assert on this.

Thanks to NAKAMURA Takumi for noticing this!

llvm-svn: 168277

llvm-svn: 168274

of a deprecated method in original class (or category), only
in overrides. // rdar://12717705

llvm-svn: 168270

This makes LexCharConstant() look more like LexStringLiteral(), which doesn't
have this bug. Add tests for eof after \ for several other cases.

llvm-svn: 168269

__has_attribute, __has_extension, making them behave more akin to
conventional macros.

llvm-svn: 168268

llvm-svn: 168267

common LexStringLiteral function.  In doing so, some consistency problems have
been ironed out (e.g. where the first token in the string literal was lexed
with macro expansion, but subsequent ones were not) and also an erroneous
diagnostic has been corrected.

LexStringLiteral is complemented by a FinishLexStringLiteral function which
can be used in the situation where the first token of the string literal has
already been lexed.

llvm-svn: 168266

llvm-svn: 168265

Also fixes a bit/byte mismatch when checking if a target supports atomic ops of a certain size.

llvm-svn: 168260

Further reduce "-fsyntax-only -Wuninitialized" time on sqlite3.c by another 2.5% using intelligent pruning of blocks during the final reporting pass.

llvm-svn: 168257

an initial baseline for enqueued blocks, but use a simple DFS stack
for propagating changes quickly up back edges.

This provides a 3.5% reduction in -fsyntax-only time on sqlite3.c.

llvm-svn: 168241

llvm-svn: 168239

Clean up X86 target feature translation code slightly.  No intended functional change.  Patch by Jung-uk Kim.

llvm-svn: 168237

Revert r167799. It's not really correct, and it doesn't fix the problem that it was intended to fix.

llvm-svn: 168217

This was causing different behavior when using -x objective-c++-cpp-output as
compared to -x objc++-cpp-output.  Specifically, the driver was not adding the
-fcxx-exceptions flag in the latter case.
rdar://12680312

llvm-svn: 168212

There are better ways of limiting the amount of information if there is a need
for that.

Patch by Philip Craig.

llvm-svn: 168206

The problem is that a partial match of an (explicit or implicit) allOf matcher
binds results, i.e.

recordDecl(decl().bind("x"), hasName("A"))

can very well bind a record that is not named "A". With this fix, the common
cases of stumbling over this bug are fixed by the BoundNodesMap overwriting the
results of a partial match. An error can still be created with a weird
combination of anyOf and allOf (see inactive test). We need to decide whether
this is worth fixing, as the fix will have performance impact.

Review: http://llvm-reviews.chandlerc.com/D124
llvm-svn: 168177

LLVM_USED_LIBS does nothing here.

llvm-svn: 168172

UBSan: enable proper linking with UBsan runtime on Darwin. Turn on building ubsan on OS X in 'make' build system. Patch by Jean-Daniel Dupas.

llvm-svn: 168168

llvm-svn: 168145

it as a pointer. 

llvm-svn: 168136

to the CodeCompletionTUInfo that is going to be used to get the results.

Previously we would use ASTUnit's CodeCompletionTUInfo which has its own allocator
that will go away when we reparse. That could result in a use-after-free bug when
getting the parent context name from a CodeCompletionString.

Addresses rdar://12568377.

llvm-svn: 168133

 - This diverges from gcc, and confuses tools (like dtrace) which track # line
   markers as a way to determine which content is in the context of the main
   file.

llvm-svn: 168128

width of an enum with negative values in IntRange.  Include a test for
-Wtautological-constant-out-of-range-compare where this had manifested.

llvm-svn: 168126

GCC 4.7 reuses stack slots fairly aggressively, which exposes more temporary
lifetime bugs.

No new test, this was caught by the existing CodeGenCXX/mangle-ms-templates.cpp.

llvm-svn: 168124

Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.

No functionality changes are intended here (they will come when the predicates
start producing the right answers...).

llvm-svn: 168119

Make sure CodeGenTypes correctly reconverts function types.  Fixes PR14355, a crash in IR generation.

llvm-svn: 168112

dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Brian Brooks!

llvm-svn: 168108

In code like this:

void foo() {
     bar();
     baz();
}

...the location for the call to 'bar()' was being used as a backup location
for the call to 'baz()'. This is fine unless the call to 'bar()' is deemed
uninteresting and that part of the path deleted.

(This looks like a logic error as well, but in practice the only way 'baz()'
could have an invalid location is if the entire body of 'foo()' is
synthesized, meaning the call to 'bar()' will be using the location of the
call to 'foo()' anyway. Nevertheless, the new version better matches the
intent of the code.)

Found by Matt Beaumont-Gay using ASan. Thanks, Matt!

llvm-svn: 168080

llvm-svn: 168077

This fixes a few cases where we'd emit path notes like this:

  +---+
 1|   v
  p = malloc(len);
  ^   |2
  +---+

In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.

llvm-svn: 168070

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168069

Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.

llvm-svn: 168068