summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
* [Modules] Make the AST serialization always use lexicographic order whenChandler Carruth2015-03-261-4/+12
| | | | | | | | | | | | | | | | traversing the identifier table. No easy test case as this table is somewhere between hard and impossible to observe as non-deterministically ordered. The table is a hash table but we hash the string contents and never remove entries from the table so the growth pattern, etc, is all completely fixed. However, relying on the hash function being deterministic is specifically against the long-term direction of LLVM's hashing datastructures, which are intended to provide *no* ordering guarantees. As such, this defends against these things by sorting the identifiers. Sorting identifiers right before we emit them to a serialized form seems a low cost for predictability here. llvm-svn: 233332
* [Modules] Delete stale, pointless code. All tests still pass with thisChandler Carruth2015-03-261-15/+0
| | | | | | | | | | | logic removed. This logic was both inserting all builtins into the identifier table and ensuring they would get serialized. The first happens unconditionally now, and we always write out the entire identifier table. This code can simply go away. llvm-svn: 233331
* [Modules] Fix a sneaky bug in r233249 where we would look for implicitChandler Carruth2015-03-261-25/+39
| | | | | | | | | | | | | | | | | constructors in the current lexical context even though name lookup found them via some other context merged into the redecl chain. This can only happen for implicit constructors which can only have the name of the type of the current context, so we can fix this by simply *always* merging those names first. This also has the advantage of removing the walk of the current lexical context from the common case when this is the only constructor name we need to deal with (implicit or otherwise). I've enhanced the tests to cover this case (and uncovered an unrelated bug which I fixed in r233325). llvm-svn: 233327
* [Modules] Fix tiny bug where we failed to get the canonical decl whenChandler Carruth2015-03-261-1/+1
| | | | | | | | | | | | | | | deserializing an inherited constructor. This is the exact same logic we use when deserializing method overrides for the same reason: the canonical decl may end up pinned to a different decl when we are improting modules, we need to re-pin to the canonical one during reading. My test case for this will come in a subsequent commit. I was trying to test a more tricky bug fix and the test case happened to tickle this bug as well. llvm-svn: 233325
* [modules] Restrict the module use-declaration to only appear in top-levelRichard Smith2015-03-262-17/+26
| | | | | | | modules, and allow sub-modules of a module with a use-declaration to make use of the nominated modules. llvm-svn: 233323
* Fix -Wshift-count-negative. It didn't work if the right hand sideDavide Italiano2015-03-261-1/+1
| | | | | | | | of the shift wasn't a constant integer expression, now it (hopefully) does. PR: 22059 llvm-svn: 233320
* clang-format: Force line break in trailing calls after multline exprs.Daniel Jasper2015-03-263-6/+8
| | | | | | | | | | | | | Before: aaaaaaaa(aaaaaaaaaa, bbbbbbbbbb).a(); After: aaaaaaaa(aaaaaaaaaa, bbbbbbbbbb) .a(); llvm-svn: 233304
* Enable -ffunction-sections and -fdata-sections for CloudABI by default.Ed Schouten2015-03-261-2/+5
| | | | | | | | | | | | | | | | | | | | | | Unlike most of the other platforms supported by Clang, CloudABI only supports static linkage, for the reason that global filesystem access is prohibited. Functions provided by dlfcn.h are not present. As we know that applications will not try to do any symbol lookups at run-time, we can garbage collect unused code quite aggressively. Because of this, it makes sense to enable -ffunction-sections and -fdata-sections by default. Object files will be a bit larger than usual, but the resulting binary will not be affected, as the sections are merged again. However, when --gc-sections is used, the linker is able to remove unused code far more more aggressively. It also has the advantage that transitive library dependencies only need to be provided to the linker in case that functionality is actually used. Differential Revision: http://reviews.llvm.org/D8635 Reviewed by: echristo llvm-svn: 233299
* clang-format: Fix merging of _T macros.Daniel Jasper2015-03-261-0/+2
| | | | | | | NewlinesBefore and HasUnescapedNewline were not properly propagated leading to llvm.org/PR23032. llvm-svn: 233276
* Let Clang invoke CloudABI's linker.Ed Schouten2015-03-265-0/+144
| | | | | | | | | | | | | | | | | | | | | | Now that CloudABI's target information and header search logic for Clang has been submitted, the only thing that remains to be done is adding support for CloudABI's linker. CloudABI uses Binutils ld, although there is some work to use lld instead. This means that this code is largely based on what we use on FreeBSD. There are some exceptions, however: - Only static linking is performed. CloudABI does not support any dynamically linked executables. - CloudABI uses compiler-rt, libc++ and libc++abi unconditionally. Link in these libraries instead of using libgcc_s, libstdc++, etc. - We must ensure that the .eh_frame_hdr is present to make C++ exceptions work properly. Differential Revision: http://reviews.llvm.org/D8250 llvm-svn: 233269
* [Modules] Preserve source order for the map of late parsed templates.Chandler Carruth2015-03-264-9/+8
| | | | | | | | | | | | | | | | | | | | Clang was inserting these into a dense map. While it never iterated the dense map during normal compilation, it did when emitting a module. Fix this by using a standard MapVector to preserve the order in which we encounter the late parsed templates. I suspect this still isn't ideal, as we don't seem to remove things from this map even when we mark the templates as no longer late parsed. But I don't know enough about this particular extension to craft a nice, subtle test case covering this. I've managed to get the stress test to at least do some late parsing and demonstrate the core problem here. This patch fixes the test and provides deterministic behavior which is a strict improvement over the prior state. I've cleaned up some of the code here as well to be explicit about inserting when that is what is actually going on. llvm-svn: 233264
* [Modules] Make "#pragma weak" undeclared identifiers be trackedChandler Carruth2015-03-263-27/+15
| | | | | | | | | | | | | | | | deterministically. This fixes a latent issue where even Clang's Sema (and diagnostics) were non-deterministic in the face of this pragma. The fix is super simple -- just use a MapVector so we track the order in which these are parsed (or imported). Especially considering how rare they are, this seems like the perfect tradeoff. I've also simplified the client code with judicious use of auto and range based for loops. I've added some pretty hilarious code to my stress test which now survives the binary diff without issue. llvm-svn: 233261
* [Modules] Delete a bunch of complex code for ensuring visible decls inChandler Carruth2015-03-262-64/+4
| | | | | | | | | | | | | | updated decl contexts get emitted. Since this code was added, we have newer vastly simpler code for handling this. The code I'm removing was very expensive and also generated unstable order of declarations which made module outputs non-deterministic. All of the tests continue to pass for me and I'm able to check the difference between the .pcm files after merging modules together. llvm-svn: 233251
* [modules] If we reach a definition of a class for which we already have aRichard Smith2015-03-268-13/+119
| | | | | | | | non-visible definition, skip the new definition and make the old one visible instead of trying to parse it again and failing horribly. C++'s ODR allows us to assume that the two definitions are identical. llvm-svn: 233250
* [Modules] A second attempt at writing out on-disk hash tables for theChandler Carruth2015-03-261-56/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | decl context lookup tables. The first attepmt at this caused problems. We had significantly more sources of non-determinism that I realized at first, and my change essentially turned them from non-deterministic output into use-after-free. Except that they weren't necessarily caught by tools because the data wasn't really freed. The new approach is much simpler. The first big simplification is to inline the "visit" code and handle this directly. That works much better, and I'll try to go and clean up the other caller of the visit logic similarly. The second key to the entire approach is that we need to *only* collect names into a stable order at first. We then need to issue all of the actual 'lookup()' calls in the stable order of the names so that we load external results in a stable order. Once we have loaded all the results, the table of results will stop being invalidated and we can walk all of the names again and use the cheap 'noload_lookup()' method to quickly get the results and serialize them. To handle constructors and conversion functions (whose names can't be stably ordered) in this approach, what we do is record only the visible constructor and conversion function names at first. Then, if we have any, we walk the decls of the class and add those names in the order they occur in the AST. The rest falls out naturally. This actually ends up simpler than the previous approach and seems much more robust. It uncovered a latent issue where we were building on-disk hash tables for lookup results when the context was a linkage spec! This happened to dodge all of the assert by some miracle. Instead, add a proper predicate to the DeclContext class and use that which tests both for function contexts and linkage specs. It also uncovered PR23030 where we are forming somewhat bizarre negative lookup results. I've just worked around this with a FIXME in place because fixing this particular Clang bug seems quite hard. I've flipped the first part of the test case I added for stability back on in this commit. I'm taking it gradually to try and make sure the build bots are happy this time. llvm-svn: 233249
* Reformatting, NFCRichard Smith2015-03-262-10/+11
| | | | llvm-svn: 233234
* Keep track of canonical decls in Redeclarable.Manuel Klimek2015-03-251-0/+4
| | | | | | | | More than 2x speedup on modules builds with large redecl chains. Roughly 15-20% speedup on non-modules builds for very large TUs. Between 2-3% cost in memory on large TUs. llvm-svn: 233228
* Reapply r232888 after applying a fix for -msse4 code generation.Eric Christopher2015-03-251-0/+21
| | | | | | | As a note, any target that uses fake target features via command line options will have similar problems. llvm-svn: 233227
* Make the msse4/mno-sse4 flags aliases of the maximum sse valuesEric Christopher2015-03-251-5/+0
| | | | | | | | | | | | | they enable/disable. This fixes two things: a) sse4 isn't actually a target feature, don't treat it as one. b) we weren't correctly disabling sse4.1 when we'd pass -mno-sse4 after enabling it, thus passing preprocessor directives and (soon) passing the function attribute as well when we shouldn't. llvm-svn: 233223
* Fix addrspace when emitting constructors of static local variablesJingyue Wu2015-03-251-0/+23
| | | | | | | | | | | | | | | | | | | | Summary: Due to CUDA's implicit address space casting, the type of a static local variable may be more specific (i.e. with address space qualifiers) than the type expected by the constructor. Emit an addrspacecast in that case. Test Plan: Clang used to crash on the added test. Reviewers: nlewycky, pcc, eliben, rsmith Reviewed By: eliben, rsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8575 llvm-svn: 233208
* Add Hardware Transactional Memory (HTM) SupportKit Barton2015-03-254-1/+441
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds Hardware Transaction Memory (HTM) support supported by ISA 2.07 (POWER8). The intrinsic support is based on GCC one [1], with both 'PowerPC HTM Low Level Built-in Functions' and 'PowerPC HTM High Level Inline Functions' implemented. Along with builtins a new driver switch is added to enable/disable HTM instruction support (-mhtm) and a header with common definitions (mostly to parse the TFHAR register value). The HTM switch also sets a preprocessor builtin HTM. The HTM usage requires a recently newer kernel with PPC HTM enabled. Tested on powerpc64 and powerpc64le. This is send along a llvm patch to enabled the builtins and option switch. [1] https://gcc.gnu.org/onlinedocs/gcc/PowerPC-Hardware-Transactional-Memory-Built-in-Functions.html Phabricator Review: http://reviews.llvm.org/D8248 llvm-svn: 233205
* Create android x86_32 and x86_64 target infoTamas Berghammer2015-03-251-4/+40
| | | | | | | | | | | On android x86_32 the long double is only 64 bits (compared to 80 bits on linux x86_32) and on android x86_64 the long double is IEEEquad (compared to x87DoubleExtended on linux x86_64). This CL creates new TargetInfo classes for this targets to represent these differences. Differential revision: http://reviews.llvm.org/D8357 llvm-svn: 233177
* Revert "[Modules] When writing out the on-disk hash table for the decl ↵Rafael Espindola2015-03-251-90/+15
| | | | | | | | context lookup tables, we need to establish a stable ordering for constructing the hash table. This is trickier than it might seem." This reverts commit r233156. It broke the bots. llvm-svn: 233172
* InstrProf: Handle whitespace and comments at the ends of macrosJustin Bogner2015-03-251-4/+4
| | | | | | | | | | | | | | | When we try to find the end loc for a token, we have to re-lex the token. This was running into a problem when we'd store the end loc of a macro's coverage region, since we wouldn't actually be at the beginning of a token when we tried to re-lex it, leading us to do silly things (and eventually assert) when whitespace or comments followed. This pushes our use of getPreciseTokenLocEnd earlier, so that we won't call it when it doesn't make sense to. It also removes an unnecessary adjustment by 1 that was working around this problem in some cases. llvm-svn: 233169
* Diagnose ref-qualifiers occuring after virt-specifier-seq and generate fixit ↵Ehsan Akhgari2015-03-252-10/+35
| | | | | | | | | | | | | | hints Summary: Follow-up to the fix of PR22075. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7012 llvm-svn: 233161
* Diagnose declspecs occuring after virt-specifier-seq and generate fixit hintsEhsan Akhgari2015-03-253-2/+55
| | | | | | | | | | | | Summary: This fixes PR22075. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6828 llvm-svn: 233160
* [Modules] When writing out the on-disk hash table for the decl contextChandler Carruth2015-03-251-15/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lookup tables, we need to establish a stable ordering for constructing the hash table. This is trickier than it might seem. Most of these cases are easily handled by sorting the lookup results associated with a specific name that has an identifier. However for constructors and conversion functions, the story is more complicated. Here we need to merge all of the constructors or conversion functions together and this merge needs to be stable. We don't have any stable ordering for either constructors or conversion functions as both would require a stable ordering across types. Instead, when we have constructors or conversion functions in the results, we reconstruct a stable order by walking the decl context in lexical order and merging them in the order their particular declaration names are encountered. This doesn't generalize as there might be found declaration names which don't actually occur within the lexical context, but for constructors and conversion functions it is safe. It does require loading the entire decl context if necessary to establish the ordering but there doesn't seem to be a meaningful way around that. Many thanks to Richard for talking through all of the design choices here. While I wrote the code, he guided all the actual decisions about how to establish the order of things. No test case yet because the test case I have doesn't pass yet -- there are still more sources of non-determinism. However, this is complex enough that I wanted it to go into its own commit in case it causes some unforseen issue or needs to be reverted. llvm-svn: 233156
* Fix obviously broken assertion, NFCReid Kleckner2015-03-241-4/+4
| | | | llvm-svn: 233138
* [CodeGen] Support native half inc/dec amounts.Ahmed Bougacha2015-03-241-1/+6
| | | | | | | | We previously defaulted to long double, but it's also possible to have a half inc/dec amount, when LangOpts NativeHalfType is set. Currently, that's only true for OpenCL. llvm-svn: 233135
* [Modules] Stop creating timestamps for the modules cache and trying toChandler Carruth2015-03-241-3/+4
| | | | | | | | | | | | | prune it when we have disabled implicit module generation and thus are not using any cached modules. Also update a test of explicitly generated modules to pass this CC1 flag correctly. This fixes an issue where Clang was dropping files into the source tree while running its tests. llvm-svn: 233117
* [Modules] Start making explicit modules produce deterministic output.Chandler Carruth2015-03-241-13/+16
| | | | | | | | | | | | | | | | | | | | | There are two aspects of non-determinism fixed here, which was the minimum required to cause at least an empty module to be deterministic. First, the random number signature is only inserted into the module when we are building modules implicitly. The use case for these random signatures is to work around the very fact that modules are not deterministic in their output when working with the implicitly built and populated module cache. Eventually this should go away entirely when we're confident that Clang is producing deterministic output. Second, the on-disk hash table is populated based on the order of iteration over a DenseMap. Instead, use a MapVector so that we can walk it in insertion order. I've added a test that an empty module, when built twice, produces the same binary PCM file. llvm-svn: 233115
* Track the source location of the dot or arrow operator in a MemberExpr.Aaron Ballman2015-03-249-230/+207
| | | | | | Patch by Joe Ranieri! llvm-svn: 233085
* Reverting r233023 -- it caused test failures on Windows with MSVC x86.Aaron Ballman2015-03-241-4/+0
| | | | | | http://bb.pgr.jp/builders/ninja-clang-i686-msc18-R/builds/572 llvm-svn: 233082
* Revert "Diagnose declspecs occuring after virt-specifier-seq and generate ↵Ehsan Akhgari2015-03-243-53/+2
| | | | | | | | fixit hints" This reverts commit 2131e63e2fdff7c831ab3bfe31facf2e3ebab03d. llvm-svn: 233074
* Revert "Diagnose ref-qualifiers occuring after virt-specifier-seq and ↵Ehsan Akhgari2015-03-242-35/+10
| | | | | | | | generate fixit hints" This reverts commit 49079d45966a3f57cd82edb35bde2e8e88fccf40. llvm-svn: 233073
* Diagnose ref-qualifiers occuring after virt-specifier-seq and generate fixit ↵Ehsan Akhgari2015-03-242-10/+35
| | | | | | | | | | | | | | hints Summary: Follow-up to the fix of PR22075. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D7012 llvm-svn: 233070
* Diagnose declspecs occuring after virt-specifier-seq and generate fixit hintsEhsan Akhgari2015-03-243-2/+53
| | | | | | | | | | | | Summary: This fixes PR22075. Reviewers: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6828 llvm-svn: 233069
* [analyzer] Remove unused function. No functional change intended.Benjamin Kramer2015-03-241-11/+0
| | | | llvm-svn: 233060
* Silence unused warning in non-assert builds.Daniel Jasper2015-03-241-0/+1
| | | | llvm-svn: 233053
* [modules] Deserialize CXXCtorInitializer list for a constructor lazily.Richard Smith2015-03-2410-109/+247
| | | | | | | | | | | | | Previously we'd deserialize the list of mem-initializers for a constructor when we deserialized the declaration of the constructor. That could trigger a significant amount of unnecessary work (pulling in all base classes recursively, for a start) and was causing problems for the modules buildbot due to cyclic deserializations. We now deserialize these on demand. This creates a certain amount of duplication with the handling of CXXBaseSpecifiers; I'll look into reducing that next. llvm-svn: 233052
* A couple of readASTFileSignature improvements (NFC)Ben Langmuir2015-03-242-20/+15
| | | | | | | | | | * Strength reduce a std::function to a function pointer, * Factor out checking the AST file magic number, * Add a brief doc comment to readAStFileSignature Thanks to Chandler for spotting these oddities. llvm-svn: 233050
* [modules] More removal of unnecessary deserialization of lexical decls.Richard Smith2015-03-241-2/+0
| | | | | | | | Even if we have no external visible declarations, we may still have external lexical decls that lookup() would import to fill its lookup table. It's simpler and faster to always take the no-deserialization path through noload_lookup. llvm-svn: 233046
* When looking for lexical decls from an external source, check all contextsRichard Smith2015-03-241-15/+21
| | | | | | | | rather than just the primary context. This is technically correct but results in no functionality change (in Clang nor LLDB) because all users of this functionality only use it on single-context DCs. llvm-svn: 233045
* Cleanup: no need to pass DefinitionKind into ParseCXXInlineMethodDefEli Bendersky2015-03-232-6/+5
| | | | | | | | | | All ParseCXXInlineMethodDef does with it is assign it on the ParsingDeclarator. Since that is passed in as well, the (single) caller may as well set the DefinitionKind, thus simplifying the code. No change in functionality. llvm-svn: 233043
* [UBSan] Use shared library for UBSan on OS X (Clang part).Alexey Samsonov2015-03-232-34/+34
| | | | | | | | | | | | | | | | | | Summary: UBSan is now used in the same way as ASan, and is supported on OSX and on iOS simulator. At the moment ASan and UBSan can't be used together due to PR21112, but I hope to resolve it soon by embedding UBSan into ASan. Test Plan: regression test suite. Reviewers: zaks.anna, kubabrecka Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D8471 llvm-svn: 233035
* Record correct source range for defaulted/deleted members.Eli Bendersky2015-03-231-0/+7
| | | | | | | | | | | | | | | | | | | Fixes https://llvm.org/bugs/show_bug.cgi?id=20744 struct A { A() = default; }; Previously the source range of the declaration of A ended at the ')'. It should include the '= default' part as well. The same for '= delete'. Note: this will break one of the clang-tidy fixers, which is going to be addessed in a follow-up patch. Differential Revision: http://reviews.llvm.org/D8465 llvm-svn: 233028
* MS ABI: lambda call operators are instance methods and should use thiscallReid Kleckner2015-03-231-0/+4
| | | | | | Fixes an issue reported by Daniel Berenyi on cfe-dev. llvm-svn: 233023
* [SDK modernizer PATCH]. Fixes a bug whereby a call to superFariborz Jahanian2015-03-231-5/+0
| | | | | | | was not converted to property-dot syntax by removing an unused code. rdar://19140267 llvm-svn: 233019
* Adds a warning for unrecognized argument to #pragma comment() on PS4.Yunzhong Gao2015-03-231-8/+16
| | | | | | | | | | | PS4 target recognizes the #pragma comment() syntax as in -fms-extensions, but only handles the case of #pragma comment(lib). This patch adds a warning if any other arguments are encountered. This patch also refactors the code in ParsePragma.cpp a little bit to make it more obvious that some codes are being shared between -fms-extensions and PS4. llvm-svn: 233015
* [UBSan] Introduce "ubsan_standalone" library (Clang part).Alexey Samsonov2015-03-231-7/+10
| | | | | | | | | | | | Get rid of "libclang_rt.san" library that used to contain sanitizer_common pieces required by UBSan if it's used in a standalone mode. Instead, build two variants of UBSan runtime: "ubsan" and "ubsan_standalone" (same for "ubsan_cxx" and "ubsan_standalone_cxx"). Later "ubsan" and "ubsan_cxx" libraries will go away, as they will embedded it into corresponding ASan runtimes. llvm-svn: 233010
OpenPOWER on IntegriCloud