Working on a better solution to this.

This reverts commit 7d4e9934e7ca83094c5cf41346966c8350179ff2.

llvm-svn: 190990

WARNING: ThreadSanitizer: data race (pid=29103)
  Write of size 8 at 0x7d64003bbf00 by main thread:
    #0 free tsan_interceptors.cc:477
    #1 __run_exit_handlers <null>:0 (libc.so.6+0x000000050cb7)

  Previous write of size 8 at 0x7d64003bbf00 by thread T78 (mutexes: write M9896):
    #0 calloc tsan_interceptors.cc:449
    #1 ...

llvm-svn: 190989

llvm-svn: 190988

llvm-svn: 190987

llvm-svn: 190986

llvm-svn: 190985

llvm-svn: 190984

Test is coming after submitting http://llvm-reviews.chandlerc.com/D1719.

llvm-svn: 190983

llvm-svn: 190982

We don't really need to perform semantic analysis on the dependent expression
anyway, so just call the cast dependent.

<rdar://problem/15012610>

llvm-svn: 190981

Before this patch, Lex() would recurse whenever the current lexer changed (e.g.
upon entry into a macro). This patch turns the recursion into a loop: the
various lex routines now don't return a token when the current lexer changes,
and at the top level Preprocessor::Lex() now loops until it finds a token.
Normally, the recursion wouldn't end up being very deep, but the recursion depth
can explode in edge cases like a bunch of consecutive macros which expand to
nothing (like in the testcase test/Preprocessor/macro_expand_empty.c in this
patch).

<rdar://problem/14569770>

llvm-svn: 190980

llvm-svn: 190979

Test that intrin.h at least parses in C++ TUs.

llvm-svn: 190978

llvm-svn: 190977

This puts all the global PassManager debugging flags, like
-print-after-all and -time-passes, behind a managed static. This
eliminates their static initializers and, more importantly, exit-time
destructors.

The only behavioral change I anticipate is that tools need to
initialize the PassManager before parsing the command line in order to
export these options, which makes sense. Tools that already initialize
the standard passes (opt/llc) don't need to do anything new.

llvm-svn: 190974

llvm-svn: 190973

This patch adds the following, more specific warning flags:

gnu-anonymous-struct
gnu-compound-literal-initializer
gnu-empty-struct
gnu-flexible-array-initializer
gnu-flexible-array-union-member
gnu-folding-constant
redeclared-class-member
gnu-redeclared-enum
gnu-union-cast
gnu-variable-sized-type-not-at-end

Patch by Peter Lewis.

llvm-svn: 190972

Patch by Eelis van der Weegen.

llvm-svn: 190971

defined with no initializer.

llvm-svn: 190970

llvm-svn: 190969

have a type.  It does warn, though.

llvm-svn: 190968

llvm-svn: 190967

1) make sure that the first two instructions of the sequence cannot
separate from each other. The linker requires that they be sequential.
If they get separated, it can still work but it will not work in all
cases because the first of the instructions mostly involves the hi part
of the pc relative offset and that part changes slowly. You would have
to be at the right boundary for this to matter.
2) make sure that this sequence begins  on a longword boundary. 
There appears to be a bug in binutils which makes some of these calculations
get messed up if the instruction sequence does not begin on a longword
boundary. This is being investigated with the appropriate binutils folks.

llvm-svn: 190966

llvm-svn: 190965

I put in the warnings because MSVC has them, but I don't think they're very
useful.

Clang does not warn about overriding flags in general, e.g. it's perfectly
fine to have -fomit-frame-pointer followed by -fno-omit-frame-pointer.

We should focus on warning where things get confusing, such as with the
/TP and /TC options. In "clang-cl /TC a.c /TP b.cc", the user might not
realize that the /TP flag will apply to both files, and we warn about that.

Differential Revision: http://llvm-reviews.chandlerc.com/D1718

llvm-svn: 190964

llvm-svn: 190963

llvm-svn: 190962

Use the DIVariable::isIndirect() flag set by the frontend instead of
guessing whether to set the machine location's indirection bit.
Paired commit with CFE.

llvm-svn: 190961

This allows us to get rid of an ugly hack in the backend.
Paired commit with LLVM.

llvm-svn: 190960

llvm-svn: 190959

-march=x86 to SLM test.

llvm-svn: 190958

Atom Silvermont.

Patch by Sriram Murali.

llvm-svn: 190957

'instancetype' for known family of methods
with related result type; such as 'init'
methods. // rdar://14987948

llvm-svn: 190956

Fixed a logic error in Module::ResolveSymbolContextForAddress(). Asking an address if its offet is greater than zero doesn't actually correctly tell us wether the address is section offset or not. A symbol could be the first symbol in a section and its offset can be zero. Also, a non-section offset lldb_private::Address can have a NULL section and calling GetOffset() will return the absolute address. To really test if an address is section offset clients should use Address::IsSectionOffset(). Also simplified the code that backs the address up by one to use the Address::Slide() function.

llvm-svn: 190955

llvm-svn: 190954

We now have symbols with floating-point type to make sure that
(double)x == (double)x comes out true, but we still can't do much with
these. For now, don't even bother trying to create a floating-point zero
value; just give up on conversion to bool.

PR14634, C++ edition.

llvm-svn: 190953

llvm-svn: 190952

Base relocation block should be aligned on a 32-bit boundary. While the PECOFF
spec mentions only aligning the blocks, and not padding them, link.exe seems
to add an extra IMAGE_REL_I386_ABSOLUTE entry (just a zeroed WORD) in order to
pad the blocks.

Patch by Ron Ofir.

llvm-svn: 190951

llvm-svn: 190950

llvm-svn: 190949