llvm-svn: 202127

llvm-svn: 202126

llvm-svn: 202125

[asan] Fix for size_t in Asan's new and delete operators on x64 FreeBSD in 32-bit mode, only for FreeBSD <= 9.2; patch by Viktor Kutuzov

llvm-svn: 202124

llvm-svn: 202123

llvm-svn: 202122

Add documentation for these attributes, it includes:
- Motivation for their existence.
- Examples on how to use them.
- Examples on how to misuse them.

llvm-svn: 202121

llvm-svn: 202120

llvm-svn: 202119

[sanitizer] fix epoch handling in deadlock detector (before the fix, we could have had edges from locks in the previous epoch to locks in the current epoch)

llvm-svn: 202118

llvm-svn: 202117

r202112 fixed the generated output which will hopefully go away soon.

llvm-svn: 202116

llvm-svn: 202115

The FormatSecurity warning group does not need to be a sub-group
of the FormatNonLiteral group.

Patch by Zach Davis!

llvm-svn: 202114

llvm-svn: 202113

llvm-svn: 202112

llvm-svn: 202111

unexpectedly closed.

llvm-svn: 202110

This allows the 'name' field to contain a path, like

{ 'type': 'directory',
  'name': '/path/to/dir',
  'contents': [ ... ] }

which not only simplifies reading and writing these files (for humans),
but makes it possible to easily modify locations via textual
replacement, which would not have worked in the old scheme.

E.g. sed s:<ROOT>:<NEW ROOT>

llvm-svn: 202109

llvm-svn: 202108

llvm-svn: 202107

sorting it. This helps uncover latent reliance on the original ordering
which aren't guaranteed to be preserved by std::sort (but often are),
and which are based on the use-def chain orderings which also aren't
(technically) guaranteed.

Only available in C++11 debug builds, and behind a flag to prevent noise
at the moment, but this is generally useful so figured I'd put it in the
tree rather than keeping it out-of-tree.

llvm-svn: 202106

[libclang] Introduce libclang APIs for creating a buffer with a JSON virtual file overlay description.

The current API only supports adding 'virtual file path' -> 'real file path' mappings.

rdar://15986708

llvm-svn: 202105

llvm-svn: 202104

the destination operand or source operand of a memmove.

It so happens that it was impossible for SROA to try to rewrite
self-memmove where the operands are *identical*, because either such
a think is volatile (and we don't rewrite) or it is non-volatile, and we
don't even register it as a use of the alloca.

However, making the 'IsDest' test *rely* on this subtle fact is... Very
confusing for the reader. We should use the direct and readily available
test of the Use* which gives us concrete information about which operand
is being rewritten.

No functionality changed, I hope! ;]

llvm-svn: 202103

These complement many of the existing accessors and make it
significantly easier to write code which needs to poke at the underlying
Use without hard coding the operand number at which it resides for
a particular instruction. No functionality changed of course.

llvm-svn: 202102

llvm-svn: 202101

llvm-svn: 202100

CharUnits::alignmentAtOffset is equivalent to llvm::MinAlign but
slightly less efficient.  Use it's implementation instead.

llvm-svn: 202099

Take advantage of CharUnits::alignmentAtOffset instead of calculating it
by hand.

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

llvm-svn: 202098

Previously the X86 backend would look for the sret attribute and handle
this for us.  inalloca takes that all away, so we have to do the return
ourselves now.

llvm-svn: 202097

llvm-svn: 202096

llvm-svn: 202095

FIXME: Implement and check x86_64-cygwin.
llvm-svn: 202094

Suppress clang/test/Driver/clang_f_opts.c for targeting cygming since r202058 is incompatible to gcc driver.

llvm-svn: 202093

ordering.

The fundamental problem that we're hitting here is that the use-def
chain ordering is *itself* not a stable thing to be relying on in the
rewriting for SROA. Further, we use a non-stable sort over the slices to
arrange them based on the section of the alloca they're operating on.
With a debugging STL implementation (or different implementations in
stage2 and stage3) this can cause stage2 != stage3.

The specific aspect of this problem fixed in this commit deals with the
rewriting and load-speculation around PHIs and Selects. This, like many
other aspects of the use-rewriting in SROA, is really part of the
"strong SSA-formation" that is doen by SROA where it works very hard to
canonicalize loads and stores in *just* the right way to satisfy the
needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the
same alloca, we test that loads downstream of the select are
speculatable around it twice. If only one of the operands to the select
needs to be rewritten, then if we get lucky we rewrite that one first
and the select is immediately speculatable. This can cause the order of
operand visitation, and thus the order of slices to be rewritten, to
change an alloca from promotable to non-promotable and vice versa.

The fix is to defer all of the speculation until *after* the rewrite
phase is done. Once we've rewritten everything, we can accurately test
for whether speculation will work (once, instead of twice!) and the
order ceases to matter.

This also happens to simplify the other subtlety of speculation -- we
need to *not* speculate anything unless the result of speculating will
make the alloca fully promotable by mem2reg. I had a previous attempt at
simplifying this, but it was still pretty horrible.

There is actually already a *really* nice test case for this in
basictest.ll, but on multiple STL implementations and inputs, we just
got "lucky". Fortunately, the test case is very small and we can
essentially build it in exactly the opposite way to get reasonable
coverage in both directions even from normal STL implementations.

llvm-svn: 202092

llvm-svn: 202091

As requested during review, compare pointers to NULL explicitly to make what's
going on more clear.

llvm-svn: 202090

Move the pointer to be adjacent to the variable instead of the type.

No functional change.

llvm-svn: 202089

Sema: Make getPreferredTypeAlign respect alignments specified with an aligned attribute on a typedef

When calculating the preferred alignment of a type, consider if a alignment
attribute came from a typedef declaration.  If one did, do not naturally align
the type.

Patch by Stephan Tolksdorf, with a little tweaking and an additional testcase by me.

llvm-svn: 202088