This is the last change in transitioning all DIScopes to have a common prefix.

llvm-svn: 177756

Test cleanup with respect to use of deprecated tmpnam function.  Also Windows port for these tests to use _tempnam.  The bulk of this patch was donated anonymously.  I've tested it on OS X and accept responsibility for it.  If I've broken anyone's platform by switching from tmpnam to mktemp for the generation of temporary file names, just let me know.  Should be easy to fix in test/support/platform_support.h

llvm-svn: 177755

llvm-svn: 177754

Summary:
For non-dynamic classes (no virtual bases), member data pointers are
simple offsets from the base of the record.  Dynamic classes use an
aggregate for member data pointers and are therefore currently
unsupported.

Unlike Itanium, the ms ABI uses 0 to represent null for polymorphic
classes.  Non-polymorphic classes use -1 like Itanium, since 0 is a
valid field offset.

Reviewers: rjmccall

CC: timurrrr, cfe-commits

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

llvm-svn: 177753

Reverted r176374. In some cases the lit.site.cfg file does not get generated in tools/clang/tools/extra.

llvm-svn: 177751

<rdar://problem/13479539> Simplify ModuleManager/GlobalModuleIndex interaction to eliminate a pile of extraneous stats().

The refactoring in r177367 introduced a serious performance bug where
the "lazy" resolution of module file names in the global module index
to actual module file entries in the module manager would perform
repeated negative stats(). The new interaction requires the module
manager to inform the global module index when a module file has been
loaded, eliminating the extraneous stat()s and a bunch of bookkeeping
on both sides.

llvm-svn: 177750

llvm-svn: 177749

llvm-svn: 177748

llvm-svn: 177747

llvm-svn: 177746

Band-aid fix for the Windows build caused by r177710. Long-term, atomic_compare_exchange_strong should be a template on Windows too...

llvm-svn: 177745

for self.GetterName where GetterName is the getter method 
for a property with name different from the property name 
(declared via a property getter attribute) // rdar://12791315

llvm-svn: 177744

Feel free to revert them (or let me know and I will revert)
if they shouldn't be.

llvm-svn: 177743

llvm-svn: 177742

llvm-svn: 177741

It turns out that

-foo;

can be an objective C method declaration. So instead of the previous
solution, recognize objective C methods only if we are in a declaration
scope.

llvm-svn: 177740

Before:
int a; // not formatted
// formatting this line only

After:
int a; // not formatted
       // formatting this line only

This makes clang-format stable independent of whether the whole
file or single lines are formatted in most cases.

llvm-svn: 177739

As the comment says, it's a little silly to cache it in the ABI code.

llvm-svn: 177738

llvm-svn: 177737

llvm-svn: 177736

We currently have a duplicated set of call instruction patterns depending
on the ABI to be followed (Darwin vs. Linux).  This is a bit odd; while the
different ABIs will result in different instruction sequences, the actual
instructions themselves ought to be independent of the ABI.  And in fact it
turns out that the only nontrivial difference between the two sets of
patterns is that in the PPC64 Linux ABI, the instruction used for indirect
calls is marked to take X11 as extra input register (which is indeed used
only with that ABI to hold an incoming environment pointer for nested
functions).  However, this does not need to be hard-coded at the .td
pattern level; instead, the C++ code expanding calls can simply add that
use, just like it adds uses for argument registers anyway.

No change in generated code expected.

llvm-svn: 177735

Currently, the sub-operand of a memrr address that corresponds to what
hardware considers the base register is called "offreg", while the
sub-operand that corresponds to the offset is called "ptrreg".

To avoid confusion, this patch simply swaps the named of those two
sub-operands and updates all uses.  No functional change is intended.

llvm-svn: 177734

PPCTargetLowering::getPreIndexedAddressParts currently provides
the base part of a memory address in the offset result, and the
offset part in the base result.  That swap is then undone again
when an MI instruction is generated (in PPCDAGToDAGISel::Select
for loads, and using .md Pat patterns for stores).

This patch reverts this double swap, to make common code and
back-end be in sync as to which part of the address is base
and which is offset.

To avoid performance regressions in certain cases, target code
now checks whether the choice of base register would be rejected
for pre-inc accesses by common code, and attempts to swap base
and offset again in such cases.  (Overall, this means that now
pre-ice accesses are generated *more* frequently than before.)

llvm-svn: 177733

The iaddroff ComplexPattern is supposed to recognize displacement
expressions that have been processed by a SelectAddressRegImm,
which means it needs to accept TargetConstant and TargetGlobalAddress
nodes.  Currently, it erroneously also accepts some other nodes,
in particular Constant and PPCISD::Lo.

While this problem is currently latent, it would cause wrong-code
bugs with a follow-on patch I'm about to commit, so this patch
tightens the ComplexPattern.  The equivalent change is made in
PPCDAGToDAGISel::Select, where pre-inc load patterns are handled
(as opposed to store patterns, the loads are handled in C++ code
without making use of the .td ComplexPattern).

llvm-svn: 177732

The xaddroff pattern is currently (mistakenly) used to recognize
the *base* register in pre-inc store patterns.  This patch replaces
those uses by ptr_rc_nor0 (as is elsewhere done to match the base
register of an address), and removes the now unused ComplexPattern.

llvm-svn: 177731

Fixes wrong lighting in some corner cases with r600g and radeonsi, e.g.
manifested by failure of two piglit/glean tests and intermittent black
patches in many apps.

Tested on SI and RS880.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62012 [radeonsi]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58150

 [r600g]

NOTE: This is a candidate for the Mesa stable branch.

Reviewed-by: Christian König <christian.koenig@amd.com>
llvm-svn: 177730

llvm-svn: 177729

llvm-svn: 177728

llvm-svn: 177727

Requires llvm r177717.

llvm-svn: 177726

Otherwise, +/- and the beginning of constants can be recognized
incorrectly.

Before:  #define A - 1
After:   #define A -1
llvm-svn: 177725

Before: the function name was stored by the compiler as a constant string
and the run-time was printing it.
Now: the PC is stored instead and the run-time prints the full symbolized frame.
This adds a couple of instructions into every function with non-empty stack frame,
but also reduces the binary size because we store less strings (I saw 2% size reduction).
This change bumps the asan ABI version to v3.

llvm part.

Example of report (now):
==31711==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa77cf1c5 at pc 0x41feb0 bp 0x7fffa77cefb0 sp 0x7fffa77cefa8
READ of size 1 at 0x7fffa77cf1c5 thread T0
    #0 0x41feaf in Frame0(int, char*, char*, char*) stack-oob-frames.cc:20
    #1 0x41f7ff in Frame1(int, char*, char*) stack-oob-frames.cc:24
    #2 0x41f477 in Frame2(int, char*) stack-oob-frames.cc:28
    #3 0x41f194 in Frame3(int) stack-oob-frames.cc:32
    #4 0x41eee0 in main stack-oob-frames.cc:38
    #5 0x7f0c5566f76c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
    #6 0x41eb1c (/usr/local/google/kcc/llvm_cmake/a.out+0x41eb1c)
Address 0x7fffa77cf1c5 is located in stack of thread T0 at offset 293 in frame
    #0 0x41f87f in Frame0(int, char*, char*, char*) stack-oob-frames.cc:12  <<<<<<<<<<<<<< this is new
  This frame has 6 object(s):
    [32, 36) 'frame.addr'
    [96, 104) 'a.addr'
    [160, 168) 'b.addr'
    [224, 232) 'c.addr'
    [288, 292) 's'
    [352, 360) 'd'

llvm-svn: 177724

Before: the function name was stored by the compiler as a constant string
and the run-time was printing it.
Now: the PC is stored instead and the run-time prints the full symbolized frame.
This adds a couple of instructions into every function with non-empty stack frame,
but also reduces the binary size because we store less strings (I saw 2% size reduction).
This change bumps the asan ABI version to v3.

compiler-rt part, llvm part will follow.

Example of report (now):
==31711==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa77cf1c5 at pc 0x41feb0 bp 0x7fffa77cefb0 sp 0x7fffa77cefa8
READ of size 1 at 0x7fffa77cf1c5 thread T0
    #0 0x41feaf in Frame0(int, char*, char*, char*) stack-oob-frames.cc:20
    #1 0x41f7ff in Frame1(int, char*, char*) stack-oob-frames.cc:24
    #2 0x41f477 in Frame2(int, char*) stack-oob-frames.cc:28
    #3 0x41f194 in Frame3(int) stack-oob-frames.cc:32
    #4 0x41eee0 in main stack-oob-frames.cc:38
    #5 0x7f0c5566f76c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
    #6 0x41eb1c (/usr/local/google/kcc/llvm_cmake/a.out+0x41eb1c)
Address 0x7fffa77cf1c5 is located in stack of thread T0 at offset 293 in frame
    #0 0x41f87f in Frame0(int, char*, char*, char*) stack-oob-frames.cc:12  <<<<<<<<<<<<<< this is new
  This frame has 6 object(s):
    [32, 36) 'frame.addr'
    [96, 104) 'a.addr'
    [160, 168) 'b.addr'
    [224, 232) 'c.addr'
    [288, 292) 's'
    [352, 360) 'd'

llvm-svn: 177723

llvm-svn: 177722

llvm-svn: 177721

Apparently one needs to set LangOptions.LineComment.

Before "//* */" got reformatted to "/ /* */" as the lexer was returning
the token sequence (slash, comment). This could also lead to weird other
stuff, e.g. for people that like to using comments like:
//****************

llvm-svn: 177720

Add missed file from r177717 commit that adds __tsan_vptr_read.

llvm-svn: 177719

llvm-svn: 177718

This is required to determine ctor/dtor vs virtual call races.
http://llvm-reviews.chandlerc.com/D566

llvm-svn: 177717

llvm-svn: 177716