summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* Effectively revert r151058 which caused Clang's unwind.h to defer toChandler Carruth2014-12-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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 isChandler Carruth2014-12-291-0/+2
| | | | | | | | | 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 warningsAndy Gibbs2014-12-292-5/+5
| | | | llvm-svn: 224932
* irgen: remove unused compiler.runtimetypespkg field.Peter Collingbourne2014-12-291-4/+0
| | | | llvm-svn: 224931
* [cmake/multilib] Teach LLDB to respect the multlib LLVM_LIBDIR_SUFFIXChandler Carruth2014-12-294-10/+10
| | | | | | | | | | | | | | | | | | | | | 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 interpreterChandler Carruth2014-12-291-0/+10
| | | | | | | | | | | 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 theChandler Carruth2014-12-291-1/+2
| | | | | | | | | | 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 multilibChandler Carruth2014-12-295-24/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 libdirChandler Carruth2014-12-292-4/+11
| | | | | | | | | | | | | | | | | | 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 whichChandler Carruth2014-12-292-4/+4
| | | | | | | | 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 threadingChandler Carruth2014-12-296-12/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 itsChandler Carruth2014-12-291-3/+3
| | | | | | | | | | | | '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 substituteChandler Carruth2014-12-293-0/+14
| | | | | | | | | | | | 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.Chandler Carruth2014-12-293-4/+9
| | | | | | | | | | | | | | 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 fileChandler Carruth2014-12-291-0/+2
| | | | | | | | | 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 toChandler Carruth2014-12-294-8/+9
| | | | | | | | | | | | | | | | | *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 operandsDavid Majnemer2014-12-292-0/+7
| | | | | | | | 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.Elena Demikhovsky2014-12-291-2/+2
| | | | llvm-svn: 224917
* Sema: Only permit permit modifiable l-values as asm output paramsDavid Majnemer2014-12-292-14/+52
| | | | | | | | | | 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.Nico Weber2014-12-292-0/+14
| | | | | | | | | | | | | | | | | | 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 ↵Craig Topper2014-12-291-1/+1
| | | | | | __builtin_ia32_cmpps512_mask. llvm-svn: 224914
* [x86] Put 'C' after 'i' on all the AVX-512 intrisics that take const ints. ↵Craig Topper2014-12-291-55/+55
| | | | | | '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 defDavid Majnemer2014-12-293-6/+11
| | | | | | | | 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 alternativesDavid Majnemer2014-12-293-0/+29
| | | | | | Verify that asm constraints have the same number of alternatives llvm-svn: 224911
* [sanitizer-common] Fixing the ASan test build failure on OS XKuba Brecka2014-12-291-0/+4
| | | | | | 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
* SemaCXX: Don't crash when annotation tokens show up before the tag nameDavid Majnemer2014-12-292-5/+13
| | | | | | | | 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
* CodeGen: Optimize emssion of zeroinitialzied arraysDavid Majnemer2014-12-281-12/+24
| | | | | | | | | 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/test/CodeGen/X86/fast-isel-call-bool.ll: Add explicit ↵NAKAMURA Takumi2014-12-281-1/+1
| | | | | | -mtriple=x86_64-unknown to satisfy x64. llvm-svn: 224907
* Don't crash on surprising tokens in default parameter template lists.Nico Weber2014-12-283-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Sema: Variable templates cannot be static bitfield membersDavid Majnemer2014-12-282-1/+7
| | | | | | | We correctly forbid variables but not variable templates. Diagnose this case instead of crashing. llvm-svn: 224905
* irgen: do not emit an extra terminator for panic thunksPeter Collingbourne2014-12-283-4/+16
| | | | | | | | Found with GoSmith. Differential Revision: http://reviews.llvm.org/D6714 llvm-svn: 224904
* Parse: Don't crash when 'typename' shows up in an attributeDavid Majnemer2014-12-283-2/+5
| | | | | | | | | 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
* Sema: Permit an atomic type to be initialized by the same atomic typeDavid Majnemer2014-12-282-1/+9
| | | | | | | | | We forgot a conversion step when initializing an atomic type with an rvalue of the same type. This fixes PR22043. llvm-svn: 224902
* [X86][ISel] Fix a regression I introduced in r224884Keno Fischer2014-12-283-5/+17
| | | | | | | | | | | | | 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
* [X86] Add missing memory variants to AVX false dependency breakingMichael Kuperstein2014-12-283-64/+99
| | | | | | | | 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
* [CodeGenPrepare] Teach when it is profitable to speculate calls to ↵Andrea Di Biagio2014-12-285-0/+415
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | @llvm.cttz/ctlz. 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
* Sema: Don't crash when an inject class name has a nested redefinitionDavid Majnemer2014-12-284-7/+20
| | | | | | | | | 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
* Scalarizer for masked load and store intrinsics.Elena Demikhovsky2014-12-282-40/+289
| | | | | | | | 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
* Lex: Don't let annotation tokens get into macro expansionDavid Majnemer2014-12-283-2/+8
| | | | | | | | | | 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
* Fix markup from r224894.Nico Weber2014-12-281-6/+6
| | | | llvm-svn: 224895
* Add stub sections about Parse, Sema, CodeGen to the internals manual.Nico Weber2014-12-281-0/+32
| | | | | | | | | | 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
* Remove unneeded include of DeclCXX.h from libParse.Nico Weber2014-12-281-1/+0
| | | | llvm-svn: 224893
* Objective-C: Serialize "more than one decl" state of ObjCMethodList.Nico Weber2014-12-276-15/+59
| | | | | | | | | | | | | | | | | 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 ↵Craig Topper2014-12-272-22/+23
| | | | | | with illegal immediates. Correctly this time. I did the wrong patterns the first time. llvm-svn: 224891
* PowerPC: CTR shouldn't fire if a TLS call is in the loopDavid Majnemer2014-12-272-1/+42
| | | | | | | | | | | | | | | 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
* Fixing another -Wunused-variable warning, this time in release builds ↵Aaron Ballman2014-12-271-3/+3
| | | | | | without asserts. NFC. llvm-svn: 224889
* Removing a variable that is set but never used, to silence a ↵Aaron Ballman2014-12-271-4/+0
| | | | | | -Wunused-but-set-variable warning; NFC. llvm-svn: 224888
* [x86] Prevent instruction selection of AVX512 cmp.ps/pd/ss/sd intrinsics ↵Craig Topper2014-12-271-15/+18
| | | | | | 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 ↵Craig Topper2014-12-272-4/+8
| | | | | | 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 ↵Craig Topper2014-12-272-26/+33
| | | | | | 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
OpenPOWER on IntegriCloud