summaryrefslogtreecommitdiffstats
path: root/clang/lib/Serialization
Commit message (Collapse)AuthorAgeFilesLines
* [OpenMP50] Add parallel master constructcchen2019-12-052-0/+21
| | | | | | | | | | | | Reviewers: ABataev, jdoerfert Reviewed By: ABataev Subscribers: rnk, jholewinski, guansong, arphaman, jfb, cfe-commits, sandoval, dreachem Tags: #clang Differential Revision: https://reviews.llvm.org/D70726
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-052-0/+2
| | | | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder. In the 2nd attempt to reapply there was a windows lit test fail, the tests were fixed to use wildcard matching. Differential Revision: https://reviews.llvm.org/D62731
* Revert "[OpenMP50] Add parallel master construct, by Chi Chun Chen."Reid Kleckner2019-12-042-21/+0
| | | | | | This reverts commit 713dab21e27c987b9114547ce7136bac2e775de9. Tests do not pass on Windows.
* Revert " Reapply af57dbf12e54 "Add support for options ↵Melanie Blower2019-12-042-2/+0
| | | | | | | -frounding-math, ftrapping-math, -ffp-model=, and -ffp-exception-behavior="" This reverts commit cdbed2dd856c14687efd741c2d8321686102acb8. Build break on Windows (lit fail)
* [OpenMP50] Add parallel master construct, by Chi Chun Chen.cchen2019-12-042-0/+21
| | | | | | | | | | | | Reviewers: ABataev, jdoerfert Reviewed By: ABataev Subscribers: jholewinski, guansong, arphaman, jfb, cfe-commits, sandoval, dreachem Tags: #clang Differential Revision: https://reviews.llvm.org/D70726
* Reapply af57dbf12e54 "Add support for options -frounding-math, ↵Melanie Blower2019-12-042-0/+2
| | | | | | | | | | ftrapping-math, -ffp-model=, and -ffp-exception-behavior=" Patch was reverted because https://bugs.llvm.org/show_bug.cgi?id=44048 The original patch is modified to set the strictfp IR attribute explicitly in CodeGen instead of as a side effect of IRBuilder Differential Revision: https://reviews.llvm.org/D62731
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-12-021-0/+22
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* Revert "[clang][modules] Add support for merging lifetime-extended temporaries"Tyker2019-12-011-22/+0
| | | | This reverts commit a3cbe1a202df6ec8e23bd55e14db254e4bc33021.
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-12-011-0/+22
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* Revert "[clang][modules] Add support for merging lifetime-extended temporaries"Tyker2019-12-011-22/+0
| | | | This reverts commit 85c74384778909789389b9012a75cfcca7964a28.
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-11-301-0/+22
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* Revert "[clang][modules] Add support for merging lifetime-extended temporaries"Tyker2019-11-301-26/+0
| | | | This reverts commit 3c7f6b439699a9cbbc0ac8d288cc70aff357446b.
* [clang][modules] Add support for merging lifetime-extended temporariesTyker2019-11-301-0/+26
| | | | | | | | | | | | | | Summary: Add support for merging lifetime-extended temporaries Reviewers: rsmith Reviewed By: rsmith Subscribers: xbolva00, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70190
* clang/Modules: Move Serialization/Module.{h,cpp} to ModuleFile, NFCDuncan P. N. Exon Smith2019-11-217-11/+11
| | | | | | | | | Remove some cognitive load by renaming clang/Serialization/Module.h to clang/Serialization/ModuleFile.h, since it declares the ModuleFile class. This also makes editing a bit easier, since the basename of the file no long conflicts with clang/Basic/Module.h, which declares the Module class. Also move lib/Serialization/Module.cpp to lib/Serialization/ModuleFile.cpp.
* clang/Modules: Sink ASTReadResult in ReadControlBlock, NFCDuncan P. N. Exon Smith2019-11-191-5/+5
| | | | | | | | Simplify the code by avoiding some state that wasn't being used. The function-level `Result` was only assigned a value other than `Success` in the handler for `OPTIONS_BLOCK_ID`, but in that case it also hits an early return. Remove it at the function-level to make it obvious that the normal case always returns `Success`.
* [NFC] Refactor representation of materialized temporariesTyker2019-11-195-7/+37
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: thakis, sammccall, ilya-biryukov, rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* Revert "[NFC] Refactor representation of materialized temporaries"Nico Weber2019-11-175-37/+7
| | | | | | This reverts commit 08ea1ee2db5f9d6460fef1d79d0d1d1a5eb78982. It broke ./ClangdTests/FindExplicitReferencesTest.All on the bots, see comments on https://reviews.llvm.org/D69360
* [NFC] Refactor representation of materialized temporariesTyker2019-11-165-7/+37
| | | | | | | | | | | | | | | Summary: this patch refactor representation of materialized temporaries to prevent an issue raised by rsmith in https://reviews.llvm.org/D63640#inline-612718 Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: rnkovacs, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69360
* clang/Modules: Error if ReadASTBlock does not find the main moduleDuncan P. N. Exon Smith2019-11-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | If ReadASTBlock does not find its top-level submodule, there's something wrong the with the PCM. Error in that case, to avoid hitting problems further from the source. Note that the Swift compiler sometimes hits a case in CompilerInstance::loadModule where the top-level submodule mysteriously does not have Module::IsFromModuleFile set. That will emit a confusing warn_missing_submodule, which was never intended for the main module. The recent audit of error-handling in ReadAST may have rooted out the real problem. If not, this commit will help to clarify the real problem, and replace a confusing warning with an error pointing at the malformed PCM file. We're specifically sniffing out whether the top-level submodule was found/processed, in case there is a malformed module file that is missing it. If there is an error encountered during ReadSubmoduleBlock the return status should already propagate through. It would be nice to detect other missing submodules around here to catch other instances of warn_missing_submodule closer to the source, but that's left as a future exercise. https://reviews.llvm.org/D70063
* clang/Modules: Clean up modules on error in ReadASTDuncan P. N. Exon Smith2019-11-111-14/+18
| | | | | | | | ReadASTBlock and ReadASTExtensions can both return failures. Be consistent and remove all the just-loaded modules, just like when ReadASTCore returns failures. https://reviews.llvm.org/D70055
* clang/Modules: Add missing diagnostics for malformed AST filesDuncan P. N. Exon Smith2019-11-111-2/+6
| | | | | | | These were found via an audit. In the case of `ParseLineTable` this is actually dead code, since parsing the line table always succeeds, but it's prudent to be defensive since it's possible an assertion there could be converted to a `true` return in the future.
* clang/Modules: Split loop in ReadAST between failable and notDuncan P. N. Exon Smith2019-11-111-1/+7
| | | | | | | | | | | | | Split a loop in ReadAST that visits the just-loaded module chain, between an initial loop that reads further from the ASTs (and can fail) and a second loop that does some preloading (and cannot fail). This makes it less likely for a reading failure to affect the AST. This is not fixing a known bug and the behaviour change may not be observable, it's just part of an audit to look at all of the error handling in the ASTReader. https://reviews.llvm.org/D70056
* clang/Modules: Use range-based for in ASTReader::ReadAST, NFCDuncan P. N. Exon Smith2019-11-111-11/+7
|
* clang/Modules: Delay err_module_file_conflict if a diagnostic is in flightDuncan P. N. Exon Smith2019-11-111-10/+7
| | | | | | | As part of an audit of whether all errors are being reported from the ASTReader, delay err_module_file_conflict if a diagnostic is already in flight when it is hit. This required plumbing an extra argument through the delayed diagnostic mechanics in DiagnosticsEngine.
* clang/Modules: Remove unused parameter from ModuleManager::removeModulesDuncan P. N. Exon Smith2019-11-102-9/+2
| | | | | | The other paremeters appear to be sufficient to determine which modules have just been loaded and need to be removed, so stop collecting and sending in that set explicitly.
* Redeclare Objective-C property accessors inside the ObjCImplDecl in which ↵Adrian Prantl2019-11-082-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | they are synthesized. This patch is motivated by (and factored out from) https://reviews.llvm.org/D66121 which is a debug info bugfix. Starting with DWARF 5 all Objective-C methods are nested inside their containing type, and that patch implements this for synthesized Objective-C properties. 1. SemaObjCProperty populates a list of synthesized accessors that may need to inserted into an ObjCImplDecl. 2. SemaDeclObjC::ActOnEnd inserts forward-declarations for all accessors for which no override was provided into their ObjCImplDecl. This patch does *not* synthesize AST function *bodies*. Moving that code from the static analyzer into Sema may be a good idea though. 3. Places that expect all methods to have bodies have been updated. I did not update the static analyzer's inliner for synthesized properties to point back to the property declaration (see test/Analysis/Inputs/expected-plists/nullability-notes.m.plist), which I believed to be more bug than a feature. Differential Revision: https://reviews.llvm.org/D68108 rdar://problem/53782400
* [OPENMP50]Add support for parallel master taskloop simd directive.Alexey Bataev2019-10-302-0/+19
| | | | Added full support for parallel master taskloop simd directive.
* Revert "[Concepts] Constraint Enforcement & Diagnostics"Vlad Tsyrklevich2019-10-282-41/+3
| | | | | This reverts commit ffa214ef22892d75340dc6720271863901dc2c90, it was causing ASAN test failures on sanitizer-x86_64-linux-bootstrap.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-252-3/+41
| | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-192-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-193-0/+20
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. llvm-svn: 375305
* [OPENMP50]Add support for master taskloop simd.Alexey Bataev2019-10-182-0/+19
| | | | | | Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
* [OPENMP]Allow priority clause in combined task-based directives.Alexey Bataev2019-10-162-0/+2
| | | | | | | The expression of the priority clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 375026
* [OPENMP]Allow final clause in combined task-based directives.Alexey Bataev2019-10-152-0/+2
| | | | | | | The condition of the final clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374942
* [Concept] Associated Constraints InfrastructureSaar Raz2019-10-154-7/+19
| | | | | | | Add code to correctly calculate the associated constraints of a template (no enforcement yet). D41284 on Phabricator. llvm-svn: 374938
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-152-0/+42
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-152-42/+0
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* Reapply: [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-152-22/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 > llvm-svn: 374841 llvm-svn: 374895
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-152-0/+42
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* Temporarily Revert [Modules][PCH] Hash input files contentEric Christopher2019-10-142-123/+22
| | | | | | | | as it's breaking a few bots. This reverts r374841 (git commit 2a1386c81de504b5bda44fbecf3f7b4cdfd748fc) llvm-svn: 374842
* [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-142-22/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 llvm-svn: 374841
* [OPNEMP]Allow num_tasks clause in combined task-based directives.Alexey Bataev2019-10-142-0/+2
| | | | | | | The expression of the num_tasks clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374819
* [OPNEMP]Allow grainsize clause in combined task-based directives.Alexey Bataev2019-10-142-0/+2
| | | | | | | The expression of the grainsize clause must be captured in the combined task-based directives, like 'parallel master taskloop' directive. llvm-svn: 374810
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-142-0/+19
| | | | | | | | | Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
* Move most CXXRecordDecl::DefinitionData bit-fields out into a separateRichard Smith2019-10-112-153/+23
| | | | | | | | | | | file. Reduces duplication and thereby reduces the risk that someone will forget to update one of these places, as I did when adding DefaultedDestructorIsConstexpr (though I've been unable to produce a testcase for which that matters so far). llvm-svn: 374484
* [OPENMP50]Support for 'master taskloop' directive.Alexey Bataev2019-10-102-0/+19
| | | | | | Added full support for master taskloop directive. llvm-svn: 374437
* [AST] ASTReader::ReadSLocEntry(): move computation of FirstDecl into the ↵Roman Lebedev2019-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | branch where it's used The existing code is not defined, you are not allowed to produce non-null pointer from null pointer (F->FileSortedDecls here). That being said, i'm not really confident this is fix-enough, but we'll see. FAIL: Clang :: Modules/no-module-map.cpp (6879 of 16079) ******************** TEST 'Clang :: Modules/no-module-map.cpp' FAILED ******************** Script: -- : 'RUN: at line 1'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-name=ab -x c++-header /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map/a.h /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map/b.h -emit-header-module -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm : 'RUN: at line 2'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify : 'RUN: at line 3'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify -DA : 'RUN: at line 4'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify -DB : 'RUN: at line 5'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify -DA -DB : 'RUN: at line 7'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -E /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm -o - | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp : 'RUN: at line 8'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -frewrite-imports -E /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm -o - | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -- Exit Code: 2 Command Output (stderr): -- /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:1526:50: runtime error: applying non-zero offset 8 to null pointer #0 0x3a9bd0c in clang::ASTReader::ReadSLocEntry(int) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:1526:50 #1 0x328b6f8 in clang::SourceManager::loadSLocEntry(unsigned int, bool*) const /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Basic/SourceManager.cpp:461:28 #2 0x328b351 in clang::SourceManager::initializeForReplay(clang::SourceManager const&) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Basic/SourceManager.cpp:399:11 #3 0x3996c71 in clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:581:27 #4 0x394f341 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:956:13 #5 0x3a8a92b in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:290:25 #6 0xaf8d62 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/tools/driver/cc1_main.cpp:250:15 #7 0xaf1602 in ExecuteCC1Tool /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/tools/driver/driver.cpp:309:12 #8 0xaf1602 in main /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/tools/driver/driver.cpp:382:12 #9 0x7f2c1eecc2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #10 0xad57f9 in _start (/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang-10+0xad57f9) SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:1526:50 in llvm-svn: 374328
* Properly handle instantiation-dependent array bounds.Richard Smith2019-10-042-1/+3
| | | | | | | | | We previously failed to treat an array with an instantiation-dependent but not value-dependent bound as being an instantiation-dependent type. We now track the array bound expression as part of a constant array type if it's an instantiation-dependent expression. llvm-svn: 373685
* Rename TypeNodes.def to TypeNodes.inc for consistency across allJohn McCall2019-10-021-2/+2
| | | | | | | | our autogenerated files. NFC. As requested by Nico Weber. llvm-svn: 373425
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-292-4/+12
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. llvm-svn: 373159
OpenPOWER on IntegriCloud