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

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

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

*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

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

llvm-svn: 224917

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

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

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

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

llvm-svn: 224912

Verify that asm constraints have the same number of alternatives

llvm-svn: 224911

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

Clang has a hack to accept definitions of structs with tag names which
have the same name as intrinsics.  However, this hack didn't guard
against annotation tokens showing up in the token stream.

llvm-svn: 224909

Create an ConstantAggregateZero upfront if we see that it is viable.
This saves us from having to manually push_back each and every
initializer and then looping back over them to determine if they are
'null'.

llvm-svn: 224908

llvm-svn: 224907

Fixes this snippet from SLi's afl fuzzer output:

  class {
      i (x = <, enum

This parsed i as a function, x as a paramter, and the stuff after < as a
template list.  This then called TryConsumeDeclarationSpecifier() which
called TryAnnotateCXXScopeToken() without checking the preconditions of
this function.  Check them before calling, like all other callers of
TryAnnotateCXXScopeToken() do.

A more readable reproducer that causes the same crash is

  class {
      void i(int x = MyTemplateClass<int, union int>::foo());
  };

The reduced version used an eof token as surprising token, but kw_int works
just as well to repro and is easier to insert into a test file.

llvm-svn: 224906

We correctly forbid variables but not variable templates.  Diagnose this
case instead of crashing.

llvm-svn: 224905

Found with GoSmith.

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

llvm-svn: 224904

isDeclarationSpecifier performs error recovers which jostles the token
stream.  Specifically, TryAnnotateTypeOrScopeToken will end up consuming
a typename token which will confuse the attribute parsing machinery as
we no-longer have something identifier-like.

llvm-svn: 224903

We forgot a conversion step when initializing an atomic type with an
rvalue of the same type.

This fixes PR22043.

llvm-svn: 224902

The else case ResultReg was not checked for validity.
To my surprise, this case was not hit in any of the
existing test cases. This includes a new test cases
that tests this path.

Also drop the `target triple` declaration from the
original test as suggested by H.J. Lu, because
apparently with it the test won't be run on Linux

llvm-svn: 224901

Adds missing memory instruction variants to AVX false dependency breaking handling. (SSE was handled in r224246)

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

llvm-svn: 224900

If the control flow is modelling an if-statement where the only instruction in
the 'then' basic block (excluding the terminator) is a call to cttz/ctlz,
CodeGenPrepare can try to speculate the cttz/ctlz call and simplify the control
flow graph.

Example:
\code
entry:
  %cmp = icmp eq i64 %val, 0
  br i1 %cmp, label %end.bb, label %then.bb

then.bb:
  %c = tail call i64 @llvm.cttz.i64(i64 %val, i1 true)
  br label %end.bb

end.bb:
  %cond = phi i64 [ %c, %then.bb ], [ 64, %entry]
\code

In this example, basic block %then.bb is taken if value %val is not zero.
Also, the phi node in %end.bb would propagate the size-of in bits of %val
only if %val is equal to zero.

With this patch, CodeGenPrepare will try to hoist the call to cttz from %then.bb
into basic block %entry only if cttz is cheap to speculate for the target.

Added two new hooks in TargetLowering.h to let targets customize the behavior
(i.e. decide whether it is cheap or not to speculate calls to cttz/ctlz). The
two new methods are 'isCheapToSpeculateCtlz' and 'isCheapToSpeculateCttz'.
By default, both methods return 'false'.
On X86, method 'isCheapToSpeculateCtlz' returns true only if the target has
LZCNT. Method 'isCheapToSpeculateCttz' only returns true if the target has BMI.

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

llvm-svn: 224899

We expected the type of a TagDecl to be a TagType, not an
InjectedClassNameType.  Introduced a helper method, Type::getAsTagDecl,
to abstract away the difference; redefine Type::getAsCXXRecordDecl to be
in terms of it.

llvm-svn: 224898

Masked vector intrinsics are a part of common LLVM IR, but they are really supported on AVX2 and AVX-512 targets. I added a code that translates masked intrinsic for all other targets. The masked vector intrinsic is converted to a chain of scalar operations inside conditional basic blocks.

http://reviews.llvm.org/D6436

llvm-svn: 224897

We'd let annotation tokens from '#pragma pack' and the like get inside a
function-like macro.  This would lead to terror and mayhem; stop the
madness early.

This fixes PR22037.

llvm-svn: 224896

llvm-svn: 224895

I'd be interested if the paragraph on Parse not knowing much about AST is
something folks agree with.  I think this used to be true after rjmccall removed
the Action interface in r112244 and I believe it's still true, but I'm not sure.
(For example, ParseOpenMP.cpp does include AST/StmtOpenMP.h.  Other than that,
Parse not using AST nodes much seems to be still true, though.)

llvm-svn: 224894

llvm-svn: 224893

This fixes PR21587, what r221933 fixed for regular programs is now also
fixed for decls coming from PCH files.

Use another bit from the count/bits uint16_t for storing the "more than one
decl" bit.  This reduces the number of bits for the count from 14 to 13.
The selector with the most overloads in Cocoa.h has ~55 overloads, so 13 bits
should still be plenty.  Since this changes the meaning of a serialized bit
pattern, also increase clang::serialization::VERSION_MAJOR.

Storing the "more than one decl" state of only the first overload isn't quite
correct, but Sema::AreMultipleMethodsInGlobalPool() currently only looks at
the state of the first overload so it's good enough for now.

llvm-svn: 224892

[x86] Prevent instruction selection of AVX512 cmp.ps/pd/ss/sd intrinsics with illegal immediates. Correctly this time. I did the wrong patterns the first time.

llvm-svn: 224891

Determining the address of a TLS variable results in a function call in
certain TLS models.  This means that a simple ICmpInst might actually
result in invalidating the CTR register.

In such cases, do not attempt to rely on the CTR register for loop
optimization purposes.

This fixes PR22034.

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

llvm-svn: 224890

llvm-svn: 224889

Removing a variable that is set but never used, to silence a -Wunused-but-set-variable warning; NFC.

llvm-svn: 224888

[x86] Prevent instruction selection of AVX512 cmp.ps/pd/ss/sd intrinsics with illegal immediates. Forgot to do this when I did SSE/SSE2/AVX/AVX2.

llvm-svn: 224887

[x86] Assert on invalid immediates in the instruction printer for cmp.ps/pd/ss/sd instead of truncating the immediate. The assembly parser and instruction selection shouldn't generate invalid immediates.

llvm-svn: 224886

[x86] Prevent llvm.x86.cmp.ps/pd/ss/sd from being selected with bad immediates. The frontend now checks this when the builtin is used. This will allow the instruction printer to not have to deal with invalid immediates on these instructions.

llvm-svn: 224885

Summary:
Consider the following IR:

  %3 = load i8* undef
  %4 = trunc i8 %3 to i1
  %5 = call %jl_value_t.0* @foo(..., i1 %4, ...)
  ret %jl_value_t.0* %5

Bools (that are the result of direct truncs) are lowered as whatever
the argument to the trunc was and a "and 1", causing the part of the
MBB responsible for this argument to look something like this:

  %vreg8<def,tied1> = AND8ri %vreg7<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg8,%vreg7

Later, when the load is lowered, it will insert

  %vreg15<def> = MOV8rm %vreg14, 1, %noreg, 0, %noreg; mem:LD1[undef] GR8:%vreg15 GR64:%vreg14

but remember to (at the end of isel) replace vreg7 by vreg15. Now for
the bug. In fast isel lowering, we mistakenly mark vreg8 as the result
of the load instead of the trunc. This adds a fixup to have
vreg8 replaced by whatever the result of the load is as well, so
we end up with

  %vreg15<def,tied1> = AND8ri %vreg15<kill,tied0>, 1, %EFLAGS<imp-def>; GR8:%vreg15

which is an SSA violation and causes problems later down the road.

This fixes PR21557.

Test Plan: Test test case from PR21557 is added to the test suite.

Reviewers: ributzka

Reviewed By: ributzka

Subscribers: llvm-commits

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

llvm-svn: 224884

intrinsic header file. Along with r224822, this should restore the build
bots to passing.

llvm-svn: 224883