making the bounds all '1', and chunking it a bit.

llvm-svn: 158598

array of a suitable size and alignment for any of a number of different
types to be stored into the character array.

The mechanisms for producing an explicitly aligned type are fairly
complex because this operation is poorly supported on all compilers.
We've spent a fairly significant amount of time experimenting with
different implementations inside of Google, and the one using explicitly
expanded templates has been the most robust.

Credit goes to Nick Lewycky for writing the first 20 versions or so of
this logic we had inside of Google. I based this on the only one to
actually survive. In case anyone is worried, yes we are both explicitly
re-contributing and re-licensing it for LLVM. =]

Once the issues with actually specifying the alignment are finished, it
turns out that most compilers don't in turn align anything the way they
are instructed. Testing of this logic against both Clang and GCC
indicate that the alignment constraints are largely ignored by both
compilers! I've come up with and used a work-around by wrapping each
alignment-hinted type directly in a struct, and using that struct to
align the character array through a union. This elaborate hackery is
terrifying, but I've included testing that caught a terrifying number of
bugs in every other technique I've tried.

All of this in order to implement a poor C++98 programmers emulation of
C++11 unrestricted unions in classes such as SmallDenseMap.

llvm-svn: 158597

clang/lib/Basic/FileManager.cpp: Detect the root directory with PathV2. It should be better fix for PR10331, or, "clang X:\foo.c" fails.

llvm-svn: 158596

ToolingTest.cpp: Fix r158592, runToolOnCode.FindsNoTopLevelDeclOnEmptyCode on msvc. LangOpts.MicrosoftExt still appends "class type_info;".

llvm-svn: 158595

It's not deterministic to iterate over SmallPtrSet. Replace it with SmallSetVector. Patch by Daniel Reynaud. rdar://11671029

llvm-svn: 158594

of typename. GCC and Clang were fine with this, but MSVC won't accept
it. Fortunately, it also doesn't need it. Yuck.

Thanks to Nakamura for pointing this out in IRC.

llvm-svn: 158593

The target specific __builtin_va_list types are now explicitly built instead
of injecting strings into the preprocessor input.

llvm-svn: 158592

Fix Sema and IRGen for atomic compound assignment so it has the right semantics when promotions are involved.
(As far as I can tell, this only affects some edge cases.)

llvm-svn: 158591

Dynamic GEPs created by SROA needed to insert extra "i32 0"
operands to index through structs and arrays to get to the
vector being indexed.

llvm-svn: 158590

These were already trying to be type parameterized over different
key/value pairs. I've realized this goal using GoogleTest's typed test
functionality. This allows us to easily replicate the tests across
different key/value combinations and soon different mapping templates.

I've fixed a few bugs in the tests and extended them a bit in the
process as many tests were only applying to the int->int mapping.

llvm-svn: 158589

llvm-svn: 158588

This happens in C++ mode right at the declaration of a struct VLA;
MallocChecker sees a bind and tries to get see if it's an escaping bind.
It's likely that our handling of this is still incomplete, but it fixes a
crash on valid without disturbing anything else for now.

llvm-svn: 158587

rather than the base class. Add a pile of boilerplate to indirect around
this.

This is pretty ugly, but it allows the super class to change the
representation of these values, which will be key for doing
a SmallDenseMap.

Suggestions on better method structuring / naming are welcome, but keep
in mind that SmallDenseMap won't have an 'unsigned' member to expose
a reference to... =/

llvm-svn: 158586

and a derived class that provides the allocation and growth strategy.

This is the first (and biggest) step toward building a SmallDenseMap
that actually behaves exactly the same as DenseMap, and supports all the
same types and interface points with the same semantics.

llvm-svn: 158585

llvm-svn: 158584

method definition that has its '{' attached to the method name without
a space.

With a method like:

-(id)meth{
.....
}

the logic in ObjCMethodDecl that determined the selector locations got
confused because it was initialized based on an end location for '{' but
that end location changed to '}' after the method was finished.

Fix this by having an immutable end location for the declarator and
for getLocEnd() get the end location from the body itself.

Fixes rdar://11659739.

llvm-svn: 158583

the address of it. Found by a checking STL implementation used on
a dragonegg builder. Sorry about this one. =/

llvm-svn: 158582

on controlling diagnostics.

llvm-svn: 158581

This is likely only the tip of the ice berg, but this particular bug
caused any double-free on a glibc system to turn into a deadlock! It is
not generally safe to either allocate or release heap memory from within
the signal handler. The 'pop_back()' in RemoveFilesToRemove was deleting
memory and causing the deadlock. What's worse, eraseFromDisk in PathV1
has lots of allocation and deallocation paths. We even passed 'true' in
a place that would have caused the *signal handler* to try to run the
'system' system call and shell out to 'rm -rf'. That was never going to
work...

This patch switches the file removal to use a vector of strings so that
the exact text needed for the 'unlink' system call can be stored there.
It switches the loop to be a boring indexed loop, and directly calls
unlink without looking at the error. It also works quite hard to ensure
that calling 'c_str()' is safe, by ensuring that the non-signal-handling
code path that manipulates the vector always leaves it in a state where
every element has already had 'c_str()' called at least once.

I dunno exactly how overkill this is, but it fixes the
deadlock-on-double free issue, and seems likely to prevent any other
issues from sneaking up.

Sorry for not having a test case, but I *really* don't know how to test
signal handling code easily....

llvm-svn: 158580

Specifically, although the bitmap context does not take ownership of the
buffer (unlike CGBitmapContextCreateWithData), the data buffer can be extracted
out of the created CGContextRef. Thus the buffer is not leaked even if its
original pointer goes out of scope, as long as
- the context escapes, or
- it is retrieved via CGBitmapContextGetData and freed.

Actually implementing that logic is beyond the current scope of MallocChecker,
so for now CGBitmapContextCreate goes on our system function exception list.

llvm-svn: 158579

Make the ".*" operator work correctly when the base is a prvalue and the field has a non-trivial copy constructor.  PR13097.

llvm-svn: 158578

We now have a proper machine code verifier pass between register
allocation and rewriting.

llvm-svn: 158577

llvm-svn: 158575

llvm-svn: 158573

llvm-svn: 158572

1. Teach Lexer that pragma lexers are like macro expansions at EOF.
2. Treat pragmas like #define/#undef when printing.
3. If we just printed a directive, add a newline before any more tokens.
(4. Miscellaneous cleanup in PrintPreprocessedOutput.cpp)

PR10594 and <rdar://problem/11562490> (two separate related problems)

llvm-svn: 158571

llvm-svn: 158570

llvm-svn: 158569

llvm-svn: 158568

llvm-svn: 158567

llvm-svn: 158566

llvm-svn: 158565

llvm-svn: 158564

Calling checkRegMaskInterference(VirtReg) checks if VirtReg crosses any
regmask operands, regardless of the registers they clobber.

llvm-svn: 158563

* Escaped "::" and "<" as needed in Doxygen comments;
* Marked up code examples with \code...\endcode;
* Documented a \param that is current, instead of a few that aren't;
* Fixed up some \file and \brief comments.

llvm-svn: 158562

llvm-svn: 158561

iaspr, espr and xpsr which also needed to have 0b10 in their mask encoding bits.

llvm-svn: 158560

* Escaped Objective-C @keywords in Doxygen comments;
* Documented more accurate \params;
* Exposed some more summaries using \brief.

llvm-svn: 158559

llvm-svn: 158558

* Escaped # characters in Doxygen comments;
* Added Doxygen markup (\brief, \code, \file, \namespace).

llvm-svn: 158557