When outputting an object we check its section to find its name, but when
looking for the section with -ffunction-section we look for the symbol name.

Break the loop by requesting a name with the private prefix when constructing
the section name. This matches the behavior before r201608.

llvm-svn: 201622

llvm-svn: 201621

_Atomic qualifier applied to a reference type.

llvm-svn: 201620

Some references to llvm-gcc were so crusty that I wasn't sure how to
proceed and so I've left them intact.

I also slipped in a quick peephole fix to use a :doc: link instead of
raw HTML link.

llvm-svn: 201619

This adds the minimum virtual file system support to start migrating
FileManager onto the VFS.

Originally discussed here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-February/035188.html

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

llvm-svn: 201618

llvm-svn: 201617

From a cursory look it seems like all the described commandline options
and such apply to clang just fine, but I'd appreciate a second opinion.

llvm-svn: 201616

This makes Clang and LLVM -Wmsvc-include clean.

I believe the correct behavior here is to avoid updating the cache when
we find the header via MSVC's search rules.

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

llvm-svn: 201615

Fix a bug where calling SBFrame::FindValue() would cause a copy of all variables in the block to be inserted in the frame's variable list, regardless of whether those same variables were there or not - which means one could end up with a frame with lots of duplicate copies of the same variables

llvm-svn: 201614

On machines that have cl.exe on PATH, the note will print the full path.

llvm-svn: 201613

Summary:
Generally the vector deleting dtor, which we model as a vtable thunk,
takes care of non-virtual adjustment and delegates to the other
destructor variants.  The other non-complete destructor variants assume
that 'this' on entry points to the virtual base subobject that first
declared the virtual destructor.

We need to change the adjustment in both the prologue and the vdtor call
setup.

Reviewers: timurrrr

CC: cfe-commits

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

llvm-svn: 201612

llvm-svn: 201611

llvm-svn: 201610

<rdar://problem/15246793> 

llvm-svn: 201609

The IR
@foo = private constant i32 42

is valid, but before this patch we would produce an invalid MachO from it. It
was invalid because it would use an L label in a section where the liker needs
the labels in order to atomize it.

One way of fixing it would be to just reject this IR in the backend, but that
would not be very front end friendly.

What this patch does is use an 'l' prefix in sections that we know the linker
requires symbols for atomizing them. This allows frontends to just use
private and not worry about which sections they go to or how the linker handles
them.

One small issue with this strategy is that now a symbol name depends on the
section, which is not available before codegen. This is not a problem in
practice. The reason is that it only happens with private linkage, which will
be ignored by the non codegen users (llvm-nm and llvm-ar).

llvm-svn: 201608

Experiment with making -Wunreachable-code more immediately useful by restricting warnings to those issued in the main file.

This warning has a whole bunch of known false positives, much of them due
to code that is "sometimes unreachable".  This can caused by code that
is conditionally generated by the preprocessor, branches that are defined
in terms of architecture-specific details (e.g., the size of a type), and
so on.  While these are all good things to address one by one, the reality
is that this warning has received little love lately.  By restricting
its purvue, we can focus on the top issues effecting main files, which
should be smaller, and then gradually widen the scope.

llvm-svn: 201607

This is quiet a bit less confusing now that TargetData was renamed DataLayout.

llvm-svn: 201606

findOrEmitSection).

Vaidas Gasiunas's patch, r201259, fixed one instance where we were always
allocating sections as text. This patch fixes the remaining buggy call sites.

No test case: This isn't breaking anything that I know of, it's just
inconsistent.

<rdar://problem/15943542>

llvm-svn: 201605

This makes it a lot easier to see what's going on from the output.

llvm-svn: 201604

pexpect had a hack to work around some old buggy platforms, and as a
result of the hack running the tests on FreeBSD produced a stream of
kernel warnings in the system log:

  Feb 5 17:19:11 feynman kernel: WARNING pid 11323 (python2.7):
    ioctl sign-extension ioctl ffffffff80087467

The hack has now been removed upstream, so remove it here too.

llvm.org/pr18749

llvm-svn: 201603

No functional change intended.

llvm-svn: 201602

llvm-svn: 201601

Make sure we don't try to print the SystemExit exception, or we will cause the containing process to exit() from under us

llvm-svn: 201600

While at it, have cmake build and test the tool if libedit is not installed,
as this dependency is now optional.

llvm-svn: 201599

llvm-svn: 201598

It doesn't conflict with any cl.exe options and it's useful for debugging.

llvm-svn: 201597

llvm-svn: 201596

llvm-svn: 201595

In rare cases the modification of one scop can effect the validity of other
scops, as code generation of an earlier scop may make the scalar evolution
functions derived for later scops less precise. The example that triggered this
patch was a scop that contained an 'or' expression as follows:

  %add13710 = or i32 %j.19, 1
    -->  {(1 + (4 * %l)),+,2}<nsw><%for.body81>

Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This
information was not available after the first scop was code generated (or
independent-blocks was run on it) and SCEV could not derive a precise SCEV
expression any more. This means we could not any more code generate this SCoP.
My current understanding is that there is always the risk that an earlier code
generation change invalidates later scops.  As the example we have seen here is
difficult to avoid, we use this occasion to guard us against all such
invalidations.

This patch "solves" this issue by verifying right before we start working on
a detected scop, if this scop is in fact still valid. This adds a certain
overhead. However the verification we run is anyways very fast and secondly
it is only run on detected scops. So the overhead should not be very large. As
a later optimization we could detect scops only on demand, such that we need
to run scop-detections always only a single time.

This should fix the single last failure in the LLVM test-suite for the new
scev-based code generation.

llvm-svn: 201593

llvm-svn: 201592

llvm-svn: 201591

llvm-svn: 201590

This is an undocumented, but reportedly widely used flag.
We don't support it, but should be able to parse it.

llvm-svn: 201588

Missed updating this test case with r201585 -- the lockable attribute is now internally represented by CapabilityAttr.

llvm-svn: 201587

Extend the test (like it is done in scan-build) to check also if the variable 
is empty or not.

llvm-svn: 201586

DeLesley Hutchins (who wrote the original thread-safety attribute functionality) and I have agreed to start migrating from lock-specific terminology to "capability"-specific terminology. This opens the door for future threading-related analysis passes so that a common nomenclature can be used.

The following attributes have been (silently) deprecated, with their replacements listed:

lockable => capability
exclusive_locks_required => requires_capability
shared_locks_required => requires_shared_capability
locks_excluded => requires_capability

There are no functional changes intended.

llvm-svn: 201585

llvm-svn: 201584

...as well as fake flexible array members: structs that end in arrays with
length 0 or 1.

Patch by Daniel Fahlgren!

llvm-svn: 201583

Summary:
This fixes several test failures when building LLVM on a MIPS host.

The failures were:
    LLVM :: DebugInfo/enum.ll
    LLVM :: DebugInfo/inlined-arguments.ll
    LLVM :: DebugInfo/member-order.ll
    LLVM :: DebugInfo/namespace.ll
    LLVM :: DebugInfo/template-recursive-void.ll
    LLVM :: DebugInfo/tu-composite.ll
    LLVM :: DebugInfo/two-cus-from-same-file.ll
    LLVM :: Linker/type-unique-simple-a.ll
    LLVM :: Linker/type-unique-simple2.ll

Reviewers: jacksprat, matheusalmeida

Reviewed By: matheusalmeida

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

llvm-svn: 201582

TargetData was renamed DataLayout back in r165242.

llvm-svn: 201581