summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
...
* [Sanitizer] Refactor sanitizer options in LangOptions.Alexey Samsonov2014-11-112-2/+2
| | | | | | | | | | | | | | | | | | Get rid of ugly SanitizerOptions class thrust into LangOptions: * Make SanitizeAddressFieldPadding a regular language option, and rely on default behavior to initialize/reset it. * Make SanitizerBlacklistFile a regular member LangOptions. * Introduce the helper class "SanitizerSet" to represent the set of enabled sanitizers and make it a member of LangOptions. It is exactly the entity we want to cache and modify in CodeGenFunction, for instance. We'd also be able to reuse SanitizerSet in CodeGenOptions for storing the set of recoverable sanitizers, and in the Driver to represent the set of sanitizers turned on/off by the commandline flags. No functionality change. llvm-svn: 221653
* Update fold-expression mangling to match cxx-abi-dev discussion.Richard Smith2014-11-101-5/+3
| | | | llvm-svn: 221623
* [c++1z] N4295: fold-expressions.Richard Smith2014-11-086-2/+47
| | | | | | | | | | | | | | | | This is a new form of expression of the form: (expr op ... op expr) where one of the exprs is a parameter pack. It expands into (expr1 op (expr2onwards op ... op expr)) (and likewise if the pack is on the right). The non-pack operand can be omitted; in that case, an empty pack gives a fallback value or an error, depending on the operator. llvm-svn: 221573
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-071-1/+1
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* MS ABI: Correctly mangle CV qualifiers from typedefsWill Wilson2014-11-051-1/+1
| | | | llvm-svn: 221344
* Implement IRGen for the x86 vectorcall conventionReid Kleckner2014-10-311-22/+31
| | | | | | | | | | | | | | | The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
* Fix the buildDavid Blaikie2014-10-311-1/+1
| | | | llvm-svn: 220974
* Fix unused-function warning differently from r220853David Blaikie2014-10-311-8/+1
| | | | | | | | | | Rather than executing this code only needed for an assertion even in a non-asserts build, just roll the function into the assert. The assertion text literally describes the two cases so it doesn't seem like this benefits much from having a separate function (& have to hassle about ifndef NDEBUG it out, etc) llvm-svn: 220970
* Make QualType::dump() produce a useful dump of the structure of the type,Richard Smith2014-10-312-17/+247
| | | | | | rather than simply pretty-printing it. llvm-svn: 220942
* ASTDumper.cpp: Appease g++, for now.NAKAMURA Takumi2014-10-311-4/+4
| | | | llvm-svn: 220940
* Refactor tree printing in AST dumping.Richard Smith2014-10-301-541/+345
| | | | | | | | | | | Instead of manually maintaining a flag indicating whether we're about to print out the last child of the parent node (to determine whether we print "`" or "|"), capture a callable to print that child and defer printing it until we either see a next child or finish the parent. No functionality change intended. llvm-svn: 220930
* clang/lib/AST/Decl.cpp: Tweak isVLATypeCapturingAllowed() for -Asserts. ↵NAKAMURA Takumi2014-10-291-1/+3
| | | | | | [-Wunused-function] llvm-svn: 220853
* Improved capturing variable-length array types in CapturedStmt.Alexey Bataev2014-10-291-1/+15
| | | | | | | | An updated implemnentation of VLA types capturing based on previously committed solution for Lambdas. This version captures the whole VLA type instead of particular variables which are part of VLA size expression and allows to use previusly calculated size of VLA type in captured regions. Required for OpenMP. Differential Revision: http://reviews.llvm.org/D5099 llvm-svn: 220850
* Objective-C. revert patch for rdar://17554063.Fariborz Jahanian2014-10-282-28/+4
| | | | llvm-svn: 220812
* Do not insert asan paddings after fields that have flexible arrays.Kostya Serebryany2014-10-271-3/+8
| | | | | | | | | | | | | | | | | | | Summary: We should avoid a tail padding not only if the last field has zero size but also if the last field is a struct with a flexible array. If/when http://reviews.llvm.org/D5478 is committed, this will also handle the case of structs with zero-sized arrays. Reviewers: majnemer, rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5924 llvm-svn: 220708
* Add the initial TypoExpr AST node for delayed typo correction.Kaelyn Takata2014-10-276-1/+14
| | | | llvm-svn: 220692
* Itanium ABI: Template template parameters are usable as substitutionsDavid Majnemer2014-10-241-10/+7
| | | | | | | | | | | | | Template template parameters weren't added to the list of substitutions. This would make the substitution map contain inaccurate mappings, leading to Clang violating the Itanium ABI and breaking compatibility with GCC. This fixes PR21351. Differential Revision: http://reviews.llvm.org/D5959 llvm-svn: 220588
* Add frontend support for __vectorcallReid Kleckner2014-10-244-0/+9
| | | | | | | | | | | | | Wire it through everywhere we have support for fastcall, essentially. This allows us to parse the MSVC "14" CTP headers, but we will miscompile them because LLVM doesn't support __vectorcall yet. Reviewed By: Aaron Ballman Differential Revision: http://reviews.llvm.org/D5808 llvm-svn: 220573
* Fix initializing TypeOfTypeLocOlivier Goffart2014-10-241-0/+8
| | | | | | | | | | | This fixes a crash in the RecursiveASTVisitor on such code __typeof__(struct F*) var[invalid]; The UnderlyingTInfo of a TypeOfTypeLoc was left uninitialized when created from ASTContext::getTrivialTypeSourceInfo This lead to a crash in RecursiveASTVisitor when trying to access it. llvm-svn: 220562
* Removing the setLBracLoc and setRBracLoc functions from CompoundStmt -- ↵Aaron Ballman2014-10-221-1/+1
| | | | | | their only use was with the AST reader, and friendship can be used to handle that. Drive-by rename of "Brac" to "Brace" for the private data members. NFC. llvm-svn: 220428
* Correct importing of the type of a TemplateArgumentDavid Blaikie2014-10-221-4/+5
| | | | | | | | | | | It's not clear how this would be tested - I imagine we should have an ASTImporter test that RAVs the new AST and checks that all the elements in it are from this ASTContext and not the foreign one... but I know little about the ASTImporter and how/where that testing might be done. (post-commit review feedback from Richard Smith on r219900) llvm-svn: 220411
* PR21327 / C++ DR1652 / C++ DR73: comparing a past-the-end pointer for oneRichard Smith2014-10-211-0/+28
| | | | | | | | complete object to a pointer to the start of another complete object does not evaluate to the constant 'false'. All other comparisons between the addresses of subobjects of distinct complete objects still do. llvm-svn: 220343
* [OPENMP] Codegen for 'private' clause in 'parallel' directive.Alexey Bataev2014-10-212-11/+22
| | | | | | | This patch generates some helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by default (with the default constructor, if any). In outlined function references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables and implicit barier is set by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables. Differential Revision: http://reviews.llvm.org/D4752 llvm-svn: 220262
* Fix the rest of PR21289: a pack expansion that we can't expand yet makes aRichard Smith2014-10-172-35/+8
| | | | | | | template specialization type dependent, even if it has no dependent template arguments. I've filed a corresponding bug against the C++ standard. llvm-svn: 220088
* Rename TemplateArgument::getTypeForDecl to getParamTypeForDecl for clarityDavid Blaikie2014-10-174-4/+4
| | | | | | Code review feedback from Richard Smith on r219900. llvm-svn: 220060
* Revert r219977, "Re-commit r217995 and follow-up patches (r217997, r218011, ↵NAKAMURA Takumi2014-10-171-20/+7
| | | | | | | | | | | | | r218053). These were" It broke some builders. I guess it'd be reproducible with --vg. Failing Tests (3): Clang :: CXX/except/except.spec/p1.cpp Clang :: SemaTemplate/instantiate-exception-spec-cxx11.cpp Clang :: SemaTemplate/instantiate-exception-spec.cpp llvm-svn: 220038
* Optimize Type::isStructureOrClassType() by reusing RT->getDecl().Yaron Keren2014-10-171-3/+4
| | | | | | | | | | | RecordType->getDecl() which maps to TagType::getDecl() is not a simple accessor but a loop on redecls in getInterestingTagDecl. isStructureOrClassType() was calling getDecl() three times performing three times the work actually required. It is optimized by calling RT->getDecl() once and reusing the result three times. llvm-svn: 220033
* D5775: Fix of assertion failure in case of non-POD unions with bitfields. ↵Artyom Skrobov2014-10-171-4/+14
| | | | | | Patch by Evgeny Astigeevich! llvm-svn: 220031
* Towards PR21289: don't lose track of unexpanded parameter packs withRichard Smith2014-10-171-28/+17
| | | | | | | non-dependent types, in CXXScalarValueInitExprs and in the nested-name-specifier or template arguments of a DeclRefExpr in particular. llvm-svn: 220028
* AST: Remove dead code from RecordLayoutBuilderDavid Majnemer2014-10-171-11/+0
| | | | | | No functionality change intended. llvm-svn: 220005
* Teach SanitizerBlacklist to blacklist by SourceLocation. NFC.Alexey Samsonov2014-10-162-4/+3
| | | | llvm-svn: 219993
* Re-commit r217995 and follow-up patches (r217997, r218011, r218053). These wereRichard Smith2014-10-161-7/+20
| | | | | | | | | | | | | | | reverted in r218058 because they triggered a rejects-valid bug in MSVC. Original commit message from r217995: Instantiate exception specifications when instantiating function types (other than the type of a function declaration). We previously didn't instantiate these at all! This also covers the pathological case where the only mention of a parameter pack is within the exception specification; this gives us a second way (other than alias templates) to reach the horrible state where a type contains an unexpanded pack, but its canonical type does not. llvm-svn: 219977
* Insert poisoned paddings between fields in C++ classes so that ↵Kostya Serebryany2014-10-162-4/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | AddressSanitizer can find intra-object-overflow bugs Summary: The general approach is to add extra paddings after every field in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings (CodeGen/CGClass.cpp). Everything is done under the flag -fsanitize-address-field-padding. The blacklist file (-fsanitize-blacklist) allows to avoid the transformation for given classes or source files. See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding Reviewers: samsonov, rnk, rsmith Reviewed By: rsmith Subscribers: majnemer, cfe-commits Differential Revision: http://reviews.llvm.org/D5687 llvm-svn: 219961
* OpenCL: Emit global variables in the constant addr space as constant globalsTom Stellard2014-10-161-1/+1
| | | | llvm-svn: 219929
* PR21246: DebugInfo: Emit the appropriate type (cv qualifiers, ↵David Blaikie2014-10-165-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | reference-ness, etc) for non-type template parameters Plumb through the full QualType of the TemplateArgument::Declaration, as it's insufficient to only know whether the type is a reference or pointer (that was necessary for mangling, but insufficient for debug info). This shouldn't increase the size of TemplateArgument as TemplateArgument::Integer is still longer by another 32 bits. Several bits of code were testing that the reference-ness of the parameters matched, but this seemed to be insufficient (various other features of the type could've mismatched and wouldn't've been caught) and unnecessary, at least insofar as removing those tests didn't cause anything to fail. (Richard - perchaps you can hypothesize why any of these checks might need to test reference-ness of the parameters (& explain why reference-ness is part of the mangling - I would've figured that for the reference-ness to be different, a prior template argument would have to be different). I'd be happy to add them in/beef them up and add test cases if there's a reason for them) llvm-svn: 219900
* Move SanitizerBlacklist object from CodeGenModule to ASTContext.Alexey Samsonov2014-10-151-27/+20
| | | | | | | | Soon we'll need to have access to blacklist before the CodeGen phase (see http://reviews.llvm.org/D5687), so parse and construct the blacklist earlier. llvm-svn: 219857
* Adding attributes to the IndirectFieldDecl that we generate for anonymous ↵Aaron Ballman2014-10-151-3/+6
| | | | | | struct/union fields. This fixes PR20930. llvm-svn: 219807
* Fix for PR21254 - Assertion in comment parserDario Domizioli2014-10-151-0/+4
| | | | | | | | | | | | | The size of the ID field in CommandInfo was narrow, leading to potential wrap-around of command IDs, causing misinterpretation later on. The patch does the following: - It extends the ID bitfield from 8 to 20 bits. - It provides a DRY definition of the number of bits for the field to avoid using literal numbers in different files. - It introduces a new assertion that checks for the wrap-around. - It adds the testcase from PR21254. llvm-svn: 219802
* Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helperReid Kleckner2014-10-141-0/+38
| | | | | | | | | | | | | | | | | This moves some code from SemaType.cpp's hasVisibleDefinition() into DeclCXX.cpp so that it can be used elsewhere. I found one other instance of code trying to do the same thing, there are probably more. Search for getInstantiatedFrom() to try to find more. No functionality change. Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5783 llvm-svn: 219714
* CodeGen: correct block mangling in ObjCSaleem Abdulrasool2014-10-141-1/+6
| | | | | | | | | | | | Mangling for blocks defined within blocks in an ObjectiveC context were also broken by SVN r219393. Because the code in mangleName assumed that the code was either C or C++, we would trigger assertions when trying to mangle the inner blocks in an ObjectiveC context. Add a test and use the ObjectiveC specific mangling when dealing with an ObjectiveC method declaration. llvm-svn: 219697
* CodeGen: correct mangling for blocksSaleem Abdulrasool2014-10-141-0/+6
| | | | | | | | | | | | | | | This addresses a regression introduced with SVN r219393. A block may be contained within another block. In such a scenario, we would end up within a BlockDecl, which is not a NamedDecl (as the names are synthesised). The cast to a NamedDecl of the DeclContext would then assert as the types are unrelated. Restore the mangling behaviour to that prior to SVN r219393. If the current block is contained within a BlockDecl, walk up to the parent DeclContext, recursively, until we have a non-BlockDecl. This is expected to be a NamedDecl. Add in a couple of asserts to ensure that the assumption that we only encounter a block within a NamedDecl or a BlockDecl. llvm-svn: 219696
* Objective-C [Sema]. Fixes a bug in comparing qualifiedFariborz Jahanian2014-10-131-48/+30
| | | | | | | | Objective-C pointer types. In this case, checker incorrectly claims incompatible pointer types if redundant protocol conformance is specified. rdar://18491222 llvm-svn: 219630
* [OPENMP] Codegen for 'if' clause in 'parallel' directive.Alexey Bataev2014-10-131-0/+15
| | | | | | | | | | | | | | | | | | | | | Adds codegen for 'if' clause. Currently only for 'if' clause used with the 'parallel' directive. If condition evaluates to true, the code executes parallel version of the code by calling __kmpc_fork_call(loc, 1, microtask, captured_struct/*context*/), where loc - debug location, 1 - number of additional parameters after "microtask" argument, microtask - is outlined finction for the code associated with the 'parallel' directive, captured_struct - list of variables captured in this outlined function. If condition evaluates to false, the code executes serial version of the code by executing the following code: global_thread_id.addr = alloca i32 store i32 global_thread_id, global_thread_id.addr zero.addr = alloca i32 store i32 0, zero.addr kmpc_serialized_parallel(loc, global_thread_id); microtask(global_thread_id.addr, zero.addr, captured_struct/*context*/); kmpc_end_serialized_parallel(loc, global_thread_id); Where loc - debug location, global_thread_id - global thread id, returned by __kmpc_global_thread_num() call or passed as a first parameter in microtask() call, global_thread_id.addr - address of the variable, where stored global_thread_id value, zero.addr - implicit bound thread id (should be set to 0 for serial call), microtask() and captured_struct are the same as in parallel call. Also this patch checks if the condition is constant and if it is constant it evaluates its value and then generates either parallel version of the code (if the condition evaluates to true), or the serial version of the code (if the condition evaluates to false). Differential Revision: http://reviews.llvm.org/D4716 llvm-svn: 219597
* [complex] Teach the other two binary operators on complex numbers (==Chandler Carruth2014-10-111-5/+17
| | | | | | | | | | | | | | | | | and !=) to support mixed complex and real operand types. This requires removing an assert from SemaChecking, and adding support both to the constant evaluator and the code generator to synthesize the imaginary part when needed. This seemed somewhat cleaner than having just the comparison operators force real-to-complex conversions. I've added test cases for these operations. I'm really terrified that there were *no* tests in-tree which exercised this. This turned up when trying to build R after my change to the complex type lowering. llvm-svn: 219570
* [complex] Teach Clang to preserve different-type operands to arithmeticChandler Carruth2014-10-111-52/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
* Bugfix for predefined expressions in dependent context.Alexey Bataev2014-10-101-1/+1
| | | | | | This bug break compilation with precompiled headers and predefined expressions in dependent context. llvm-svn: 219525
* Change how we distinguish bitfield widths, in-classJohn McCall2014-10-101-32/+17
| | | | | | | | initializers, and captured VLA types so that we can answer questions like "is this a bit-field" without looking at the enclosing DeclContext. NFC. llvm-svn: 219522
* Reduce double set lookups. NFC.Benjamin Kramer2014-10-101-2/+1
| | | | llvm-svn: 219504
* Fix for bug http://llvm.org/PR17427.Alexey Bataev2014-10-094-37/+57
| | | | | | | | Assertion failed: "Computed __func__ length differs from type!" Reworked PredefinedExpr representation with internal StringLiteral field for function declaration. Differential Revision: http://reviews.llvm.org/D5365 llvm-svn: 219393
* [OPENMP] 'omp teams' directive basic support.Alexey Bataev2014-10-093-0/+35
| | | | | | Includes parsing and semantic analysis for 'omp teams' directive support from OpenMP 4.0. Adds additional analysis to 'omp target' directive with 'omp teams' directive. llvm-svn: 219385
OpenPOWER on IntegriCloud