[Hexagon] Removing old newvalue store variants.  Adding postincrement immediate newvalue stores.

llvm-svn: 225009

[mips][microMIPS] Relocate with symbol for micromips symbols
Differential Revision: http://reviews.llvm.org/D6796

llvm-svn: 225008

[Hexagon] Adding indexed store new-value variants.

llvm-svn: 225007

[Hexagon] Adding indexed store of immediates.

llvm-svn: 225006

[Hexagon] Adding indexed stores.

llvm-svn: 225005

Remove a comment that appears a second time 22 lines further down.

llvm-svn: 225004

x86_64: Fix calls to __morestack under the large code model.

Under the large code model, we cannot assume that __morestack lives within
2^31 bytes of the call site, so we cannot use pc-relative addressing. We
cannot perform the call via a temporary register, as the rax register may
be used to store the static chain, and all other suitable registers may be
either callee-save or used for parameter passing. We cannot use the stack
at this point either because __morestack manipulates the stack directly.

To avoid these issues, perform an indirect call via a read-only memory
location containing the address.

This solution is not perfect, as it assumes that the .rodata section
is laid out within 2^31 bytes of each function body, but this seems to
be sufficient for JIT.

Differential Revision: http://reviews.llvm.org/D6787

llvm-svn: 225003

[asan] add flag coverage_pcs. When false, the coverage is not dumped as PCs. Useful e.g. if the user only needs coverage is bitset

llvm-svn: 225002

Reapply debug info changes now that more precise column information is available.

(recommitting as the Clang patch is back in with the latest fix -
hopefully it sticks)

llvm-svn: 225001

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225000

[asan] change _sanitizer_cov_module_init to accept int* instead of int**

llvm-svn: 224999

[COFF] Don't try to add quotes to already quoted linker directives

If a linker directive is already quoted, don't try to quote it again, otherwise it creates a mess.
This pops up in places like:
#pragma comment(linker,"\"/foo bar'\"")

Differential Revision: http://reviews.llvm.org/D6792

llvm-svn: 224998

[Hexagon] Adding reg-reg indexed load forms.

llvm-svn: 224997

Driver: use the canonical library prefix on Windows

Unlike Unices, Windows does not use a library prefix.  Use the traditional
naming scheme even for Windows itanium environments.  This makes the builtins
behave more like the sanitisers as well.

llvm-svn: 224996

Add non-const version getFileSystemOpts() access function.
All the other get*Opts have both versions.

llvm-svn: 224995

The __morestack function is only available on i386 and x86_64 architectures.

llvm-svn: 224994

Make the __morestack function available to the JIT memory manager under Linux.

This function's implementation lives in libgcc, a static library, so we need
to expose it explicitly, like the other such functions.

Differential Revision: http://reviews.llvm.org/D6788

llvm-svn: 224993

[Hexagon] Dropping old combine instructions without encodings.

llvm-svn: 224992

[Hexagon] Adding compare byte/halfword reg-reg/reg-imm forms.  Adding compare to general register reg-imm form.

llvm-svn: 224991

Cleanup lldb-mi test cases.
Following changes were done.
1. Remove the extra line after -exec-run.
2. Remove check for prompt.
3. Remove 'quit' command.

Initial patch was contributed by ki.stfu@gmail.com.

llvm-svn: 224990

[Hexagon] Updating constant extender def, adding alu-not instructions, compare to general register, and inverted compares.

llvm-svn: 224989

Follow-up to r224987: fix a lint warning

llvm-svn: 224988

[ASan/Win] Sort the list of modules when we fail to reserve the shadow memory range

llvm-svn: 224987

Some code improvements in Masked Load/Store.
No functional changes.

llvm-svn: 224986

Remove doesSectionRequireSymbols.

In an assembly expression like

bar:
.long L0 + 1

the intended semantics is that bar will contain a pointer one byte past L0.

In sections that are merged by content (strings, 4 byte constants, etc), a
single position in the section doesn't give the linker enough information.
For example, it would not be able to tell a relocation must point to the
end of a string, since that would look just like the start of the next.

The solution used in ELF to use relocation with symbols if there is a non-zero
addend.

In MachO before this patch we would just keep all symbols in some sections.

This would miss some cases (only cstrings on x86_64 were implemented) and was
inefficient since most relocations have an addend of 0 and can be represented
without the symbol.

This patch implements the non-zero addend logic for MachO too.

llvm-svn: 224985

reverted prev commit (it was a mistake)

llvm-svn: 224984

v

llvm-svn: 224983

Add a public accessor for GlobalCtors in CodeGenModule

Summary:
In a JIT context it is useful to be able to access the GlobalCtors
and especially clear them once they have been emitted and called.
This adds a public method to be able to access the list.

Subscribers: yaron.keren, cfe-commits

Differential Revision: http://reviews.llvm.org/D6790

llvm-svn: 224982

Add IRBuilder routines for gc.statepoints, gc.results, and gc.relocates

Nothing particularly interesting, just adding infrastructure for use by in tree users and out of tree users.

Note: These were extracted out of a working frontend, but they have not been well tested in isolation.

Differential Revision: http://reviews.llvm.org/D6807

llvm-svn: 224981

Simplify test a bit.

It looks like the original intent was to check which symbols were created.
With macho-dump the sections were being checked just to match which symbol
was in which section.

llvm-objdump prints the section a symbol is in.

llvm-svn: 224980

[OCaml] Fix bitrot in tests.

llvm-svn: 224979

[lit] Make config.llvm_lib_dir available on cmake, too.

The OCaml tests require config.llvm_lib_dir to determine
the OCaml package search path.

llvm-svn: 224978

[OCaml] [cmake] Use LLVM_LIBRARY_DIR instead of LLVM_LIBRARY_OUTPUT_INTDIR.

The latter variable is internal.

Original patch by Ramkumar Ramachandra <artagnon@gmail.com>

llvm-svn: 224977

Testcases for r224939.

llvm-svn: 224976

Driver: unify addClangRT{Linux,Windows}

The differences are pretty superficial:
- .lib vs .a extensions
- whether or not to link (potentially) incorrectly against libgcc_s

llvm-svn: 224975

Don't crash on an invalid trailing return type on a function before a '...'

clang tries to produce a helpful diagnostic for the traiilng '...', but the
code that r216778 added for this doesn't expect an invalid trailing return type.
Add code to explicitly handle this.

Having explicit code for this but not for other things looks a bit strange, but
trailing return types are special in that they have a separate existence bit in
addition to the type (see r158348).

llvm-svn: 224974

Convert test to llvm-readobj. NFC.

llvm-svn: 224973

Revert "UBSan: Teach isDerivedFromAtOffset and findBaseAtOffset about vbases"

This reverts commit r221445. This change leads to false positives
reports from -fsanitize=vptr. See original commit thread for more
details.

llvm-svn: 224972

Semantic tests for memory invalidation at statepoints

These are simply a collection of tests intended to show that information about the contents of gc references in the heap is lost at a statepoint. I've tried to write them so that they don't disallow correct transformations, while still being fairly easy to understand.

p.s. Ideas for additional tests are welcome.

Differential Revision: http://reviews.llvm.org/D6491

llvm-svn: 224971

Revert "DebugInfo: Generalize debug info location handling"

Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.

This reverts commit r224941.

llvm-svn: 224970

Revert "Reapply debug info changes now that r224385 has been recommitted to clang (in r224941)"

Asserting when building compiler-rt when using a gcc host compiler.
Reverting while I investigate.

This reverts commit r224942.

llvm-svn: 224969

Carry facts about nullness and undef across GC relocation

This change implements four basic optimizations:

    If a relocated value isn't used, it doesn't need to be relocated.
    If the value being relocated is null, relocation doesn't change that. (Technically, this might be collector specific. I don't know of one which it doesn't work for though.)
    If the value being relocated is undef, the relocation is meaningless.
    If the value being relocated was known nonnull, the relocated pointer also isn't null. (Since it points to the same source language object.)

I outlined other planned work in comments.

Differential Revision: http://reviews.llvm.org/D6600

llvm-svn: 224968

Fix build breakage

That's what I get for last second changes...

llvm-svn: 224967

Parse: Recover more gracefully from extra :: tokens before a {

Instead of crashing, recover by eating the extra trailing scope
qualifier.  This means we will treat 'struct A:: {' as 'struct A {'.

llvm-svn: 224966

Refine the notion of MayThrow in LICM to include a header specific version

In LICM, we have a check for an instruction which is guaranteed to execute and thus can't introduce any new faults if moved to the preheader. To handle a function which might unconditionally throw when first called, we check for any potentially throwing call in the loop and give up.

This is unfortunate when the potentially throwing condition is down a rare path. It prevents essentially all LICM of potentially faulting instructions where the faulting condition is checked outside the loop. It also greatly diminishes the utility of loop unswitching since control dependent instructions - which are now likely in the loops header block - will not be lifted by subsequent LICM runs.

define void @nothrow_header(i64 %x, i64 %y, i1 %cond) {
; CHECK-LABEL: nothrow_header
; CHECK-LABEL: entry
; CHECK: %div = udiv i64 %x, %y
; CHECK-LABEL: loop
; CHECK: call void @use(i64 %div)
entry:
  br label %loop
loop: ; preds = %entry, %for.inc
  %div = udiv i64 %x, %y
  br i1 %cond, label %loop-if, label %exit
loop-if:
  call void @use(i64 %div)
  br label %loop
exit:
  ret void
}

The current patch really only helps with non-memory instructions (i.e. divs, etc..) since the maythrow call down the rare path will be considered to alias an otherwise hoistable load.  The one exception is that it does kick in for loads which are known to be invariant without regard to other possible stores, i.e. those marked with either !invarant.load metadata of tbaa 'is constant memory' metadata.

Differential Revision: http://reviews.llvm.org/D6725

llvm-svn: 224965

[cmake/multilib] Teach llgo to respect the LLVM_LIBDIR_SUFFIX variable for
multilib build and installs.

Summary:
This requires introducing a generated header to encapsulate the
LLVM_LIBDIR_SUFFIX value from the build system and push it into the go
code. From there, I've adjusted the gllgo code to systematically use
this rather than a raw "lib". This requires some awkwardness as one of
the flags *must* be "lib"-relative for compatibility with how gccgo
works. For that flag, we use ".." to back up a directory and then go
into the proper lib directory.

Differential Revision: http://reviews.llvm.org/D6795

llvm-svn: 224964

PR22051: Missing debug location on calls in dtor thunks in Windows.

llvm-svn: 224963

[go] Teach the go cmake build functions to funnel the include directories down into the cgo-setup variables of llvm-go.

Summary:
This in turn allows us to use #includes with cgo that rely on CMake
provided include directories which is particularly useful for handling
generated headers that aren't reasonable to put in an "installable"
location.

Differential Revision: http://reviews.llvm.org/D6798

llvm-svn: 224962

Loading from null is valid outside of addrspace 0

This patches fixes a miscompile where we were assuming that loading from null is undefined and thus we could assume it doesn't happen.  This transform is perfectly legal in address space 0, but is not neccessarily legal in other address spaces.

We really should introduce a hook to control this property on a per target per address space basis.  We may be loosing valuable optimizations in some address spaces by being too conservative.

Original patch by Thomas P Raoux (submitted to llvm-commits), tests and formatting fixes by me.

llvm-svn: 224961

Use std::find_if instead of manual loop.

llvm-svn: 224960

Convert test to llvm-readobj. NFC.

llvm-svn: 224959

Crash even less on malformed attributes in an incorrect location.

This is a follow-up to r224915.  This adds a bit more line noise to the tests
added in that revision to make sure the parser is ready for a toplevel decl
after each incorrect line.  Use this to move the tests up to where they belong.
This uncovered that the early return was missing a call to
ActOnTagDefinitionError(), so add that. (Also fixes at least one of the crashes
on SLi's bot.)

llvm-svn: 224958

[Hexagon] Adding allocframe, post-increment circular immediate stores, post-increment circular register stores, and bit reversed post-increment stores.

llvm-svn: 224957

Fix use-after-destruction introduced in r224924.

getMainExecutable() returns a std::string, assigning its result
to StringRef immediately creates a dangling pointer. This was
detected by half-broken fast-MSan-bootstrap bot.

llvm-svn: 224956

[Hexagon] Fixing 224952 where an addressing mode update was missed.

llvm-svn: 224955

Driver: convert a couple more instances to range based loops

More conversion to range based for loops rather than direct iterators with
dereferencing.  NFC.

llvm-svn: 224954

Remove unnecessary StringRef->std::string conversion.

llvm-svn: 224953

[Hexagon] Adding post-increment register form stores and register-immediate form stores with tests.

llvm-svn: 224952

[Hexagon] Replacing the remaining postincrement stores with versions that have encoding bits.

llvm-svn: 224951

Convert test to FileCheck. NFC.

llvm-svn: 224950

[Hexagon] Renaming old multiclass for removal.  Adding post-increment store classes and instruction defs.

llvm-svn: 224949

[py3] Teach the CMake build to reject Python versions older than 2.7.
Continue to require Python 2 however as recent experiments suggest
LLDB's build requires it.

llvm-svn: 224948

[py3] Make this test compatible with Python 3 where bytes and
strings don't mix so easily. This fixes the last remaining failure
I have in 'check-all' on a system with both Python3 and and Python2
installed.

llvm-svn: 224947

Remove darwin_fat.mk.

Summary:
Its seems to be replaced by clang_darwin.mk in the Makefile-based
build, and is only referenced in unittest scripts, which are
broken for a long time now.

Test Plan: n/a

Reviewers: bob.wilson

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D6574

llvm-svn: 224946

Parse: Ignore '::' in 'struct :: {'

Let's pretend that we didn't see the '::' instead of go on believing
that we've got some anonymous, but globally qualified, struct.

llvm-svn: 224945

Driver: convert a number of loops to range based

Iterate over the arguments via range based for loops rather than iterators and
explicitly dereferencing them.  NFC.

llvm-svn: 224944

Add an assertion to verify a container is non-empty before calling 'back()'

This would've helped stabilize/deflake some failures that were seen
after some recent changes.

llvm-svn: 224943

Reapply debug info changes now that r224385 has been recommitted to clang (in r224941)

llvm-svn: 224942

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224941

[X86] Fix some cases where some 8-bit instructions were marked as being convertible to three address instructions, but aren't really.

llvm-svn: 224940

[X86] Add the 0x82 instructions to the disassebmler. They are identical in functionality to the 0x80 opcode instructions, but are not valid in 64-bit mode.

llvm-svn: 224939

[x86] Refactor some tablegen instruction info classes slightly to prepare for another change. NFC.

llvm-svn: 224938

[x86] Remove unused classes from tablegen instruction info.

llvm-svn: 224937

Add segmented stack support for DragonFlyBSD.

Patch by Michael Neumann.

llvm-svn: 224936

Refactor duplicated code.

No intended functionality change.

llvm-svn: 224935

Effectively revert r151058 which caused Clang's unwind.h to defer to
libunwind in all cases when installed.

At the time, Clang's unwind.h didn't provide huge chunks of the
LSB-specified unwind interface, and was generally too aenemic to use for
real software. However, it has since then become a strict superset of
the APIs provided by libunwind on Linux. Notably, you cannot compile
llgo's libgo library against libunwind, but you can against Clang's
unwind.h. So let's just use our header. =] I've checked pretty
thoroughly for any incompatibilities, and I am not aware of any.

An open question is whether or not we should continue to munge
GNU_SOURCE here. I didn't touch that as it potentially has compatibility
implications on systems I cannot easily test -- Darwin. If a Darwin
maintainer can verify that this is in fact unnecessary and remove it,
cool. Until then, leaving it in makes this change a no-op there, and
only really relevant on Linux systems where it is pretty clearly the
right way to go.

llvm-svn: 224934

Add a missing declaration to our unwind.h implementation. This is
necessary to be fully compatible with existing software that calls into
the linux unwind code. You can find documentation of this API and why it
exists in the discussion abot NPTL here:
https://gcc.gnu.org/ml/gcc-patches/2003-09/msg00154.html

llvm-svn: 224933

Fix trivial signed/unsigned comparison warnings

llvm-svn: 224932

irgen: remove unused compiler.runtimetypespkg field.

llvm-svn: 224931

[cmake/multilib] Teach LLDB to respect the multlib LLVM_LIBDIR_SUFFIX
variable (now provided both by the normal parent LLVM CMake files and by
the LLVMConfig.cmake file used by the standalone build).

This allows LLDB to build into and install into correctly suffixed
libdirs. This is especially significant for LLDB because the python
extension building done by CMake directly uses multilib suffixes when
the host OS does, and the host OS will not always look back and forth
between them. As a consequence, before LLVM, Clang, and LLDB (and every
other subproject) had support for using LLVM_LIBDIR_SUFFIX, you couldn't
build or install LLDB on a multilib system with its python extensions
enabled. With this patch (on top of all the others I have submitted
throughout the project), I'm finally able to build and install LLDB on
my system with Python support enabled. I'm also able to actually run the
LLDB test suite, etc. Now, a *huge* number of the tests still fail on my
Linux system, but hey, actually running them and them testing the
debugger is a huge step forward. =D

llvm-svn: 224930

[cmake] Teach the standalone CMake build to find the Python interpreter
the same way the LLVM CMake build does, notably using the proper CMake
module and specifically requesting an older Python version. LLDB relies
pretty heavily on not using Python 3 at this point, and without this
patch it ends up trying to use Python 3 which ends quite badly. =] With
this, I'm able to build LLDB in its standalone mode successfully on
Linux when I have both Python 2.7 and Python 3.3 installed.

llvm-svn: 224929

[cmake/multilib] Support multilib libdir suffixes by applying the
LLVM_LIBDIR_SUFFIX variable to one place in the cmake file.

This is all that I had to do to get everything from compiler-rt working
for me, but there may be more work required if folks are relying on more
parts of compiler-rt. Notably, I'm mostly using it for the sanitizers.

llvm-svn: 224928

[cmake/multilib] Teach libc++abi's CMake build to support multilib
libdir suffixes like 'lib64' or 'lib32'.

This support is currently very rhudimentary. We define a variable
LIBCXXABI_LIBDIR_SUFFIX. In a standalone build of libc++abi this can be
directly set as a cached variable to control the multilib suffix used.
When building libc++abi within a larger LLVM build, it is hard wired to
whatever LLVM libdir suffix has been selected. If this doesn't work for
someone, just let me know. I'm happy to change it.

Unfortunately, libc++abi's lit setup made this somewhat problematic to
change. It was setting variables up in a way that caused the resulting
build to not work with lit at all. To fix that, I've moved some
variables around in the CMake build to more closely match where and how
they are defined in the libc++ CMake build. This includes specifically
defining a library root variable in the CMake build where the libdir
suffix can be applied, and then using that rather than re-computing it
from the object directory in the lit config.

This is essentially new functionality for libc++abi so I don't expect it
to have any impact for folks until they start setting these variables.
However, I know libc++abi is built in a diverse set of environments so
just let me know if this causes you any problems.

llvm-svn: 224927

[cmake/multilib] Teach libc++'s CMake build to support multilib libdir
suffixes like 'lib64' or 'lib32'.

This support is currently very rhudimentary. We define a variable
LIBCXX_LIBDIR_SUFFIX. In a standalone build of libc++ this can be
directly set as a cached variable to control the multilib suffix used.
When building libc++ within a larger LLVM build, it is hard wired to
whatever LLVM libdir suffix has been selected. If this doesn't work for
someone, just let me know. I'm happy to change it.

This is essentially new functionality for libc++ so I don't expect it to
have any impact for folks until they start setting these variables.
However, I know libc++ is built in a diverse set of environments so just
let me know if this causes you any problems.

llvm-svn: 224926

[multilib] Teach LLD's CMake build to use LLVM_LIBDIR_SUFFIX which
allows it to support multilib suffixed hosts using lib64, etc. This
variable is now available both in the direct LLVM build and from the
LLVMConfig.cmake file used by standalone builds.

llvm-svn: 224925

[multilib] Teach Clang's code about multilib by threading
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.

Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.

This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.

I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.

Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.

llvm-svn: 224924

[cmake] Teach the Clang CMake build to use LLVM_LIBDIR_SUFFIX for its
'lib' directories in the build. This variable is available now both as
part of the normal LLVM build an as part of a standalone build as I've
added it to the LLVMConfig.cmake output.

With this change we should at least put libraries into the multilib
directory correctly. It is the first step in getting Clang to be
reasonably multilib aware.

llvm-svn: 224923

[multilib] Add support to the autoconf build to substitute
a CLANG_LIBDIR_SUFFIX variable. This is necessary before I can add
support for using that variable to CMake and the C++ code in Clang, and
the autoconf build system does all substitutions in the LLVM tree.

As mentioned before, I'm not planning to add actual multilib support to
the autoconf build, just enough stubs for it to keep playing nicely with
the CMake build once that one has support.

llvm-svn: 224922

[cmake] Teach the llvm-config program to respect LLVM_LIBDIR_SUFFIX.

For this to work, we have to encode it in the build variables and use it
from llvm-config.cpp. I've tried to do this reasonably cleanly, but the
code for llvm-config.cpp is pretty strange. However, with this,
llvm-config stops giving the wrong answer when using LLVM_LIBDIR_SUFFIX.

Note that the configure+make build just sets this to an empty string as
that build system has zero support for multilib of any form. I'm not
planning to add support there either, but this should leave a path for
anyone that wanted to.

llvm-svn: 224921

[cmake] Push LLVM_LIBDIR_SUFFIX through to the LLVMConfig.cmake file
that is used by other projects to build against LLVM. This will allow
subsequent patches to them to use LLVM_LIBDIR_SUFFIX, both when built as
part of the larger LLVM build an as part of a standalone build against
an installed set of LLVM libraries.

llvm-svn: 224920

[cmake] Start making LLVM_LIBDIR_SUFFIX effective by adding it to
*numerous* places where it was missing in the CMake build. The primary
change here is that the suffix is now actually used for all of the lib
directories in the LLVM project's CMake. The various subprojects still
need similar treatment.

This is the first of a series of commits to try to make LLVM's cmake
effective in a multilib Linux installation. I don't think many people
are seriously using this variable so I'm hoping the fallout will be
minimal. A somewhat unfortunate consequence of the nature of these
commits is that until I land all of them, they will in part make the
brokenness of our multilib support more apparant. At the end, things
should actually work.

llvm-svn: 224919

Sema: Permit array l-values in asm output operands

GCC permits array l-values in asm output operands even though they
aren't modifiable l-values.  We used to permit it but this behavior
regressed in r224916.

llvm-svn: 224918

Fixed 2 minor typos in the documentation.

llvm-svn: 224917

Sema: Only permit permit modifiable l-values as asm output params

Functions are l-values in C++ but shouldn't be available as output
parameters in inline assembly.  Neither should overloaded function
l-values.

This fixes PR21949.

llvm-svn: 224916

Don't crash on malformed attributes in an incorrect location.

r168626 added nicer diagnostics for attributes in the wrong places, such as
after the `final` on a class.  To do this, it added code that did high-level
pattern matching for e.g. 'final' 'alignas' '(' and then skipped until the
closing ')'.  If it saw that, it then went down the regular class parsing
path and then called MaybeParseCXX11Attributes() to parse the attribute after
the 'final' using real attribute parsing code.  On invalid attributes, the
real attribute parsing code could eat more tokens than the pattern matching
code and for example skip past the '{' starting the class, which would then
lead to an assert.  To prevent this, check for a good state after calling
MaybeParseCXX11Attributes() (which morphed into CheckMisplacedCXX11Attribute()
in r175575) and bail out if things look bleak.

Found by SLi's afl bot.

llvm-svn: 224915

[x86] Fix an accidental commit of a change from Ii to iC on __builtin_ia32_cmpps512_mask.

llvm-svn: 224914

[x86] Put 'C' after 'i' on all the AVX-512 intrisics that take const ints. 'C' is a suffix modifier not a prefix modififier. Also put 'C' on the pointers in all of the gather instrinsics. I think they previously had one due to the misordering. I'm still thinking the 'iC' actually need to be a 'Ii' since they really require an ICE.

llvm-svn: 224913

Sema: Don't crash when solitary :: token appears before { in struct def

hasDeclaratorForAnonDecl, getDeclaratorForAnonDecl and
getTypedefNameForAnonDecl are expected to handle the case where
NamedDeclOrQualifier holds the wrong type or nothing at all.

llvm-svn: 224912

Sema: Forbid inconsistent constraint alternatives

Verify that asm constraints have the same number of alternatives

llvm-svn: 224911

[sanitizer-common] Fixing the ASan test build failure on OS X

The change in r224819 started using internal_unlink in a sanitizer_common unit test. For some reason, internal_unlink is not defined in sanitizer_mac.cc, fixing that.

llvm-svn: 224910