TTom Stellard[clang][Sema] Fix a clang crash with btf_type_tag
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[clang][APINotes] Fix -Wunused-function warning (NFC) GCC warning: /llvm-project/clang/lib/APINotes/APINotesYAMLCompiler.cpp:574:23: warning: ‘void {anonymous}::Module::dump()’ defined but not used [-Wunused-function] 574 | LLVM_DUMP_METHOD void Module::dump() { | ^~~~~~ | 5 年前 | |
Revert "[clang] Implement ElaboratedType sugaring for types written bare" This reverts commit 7c51f02effdbd0d5e12bfd26f9c3b2ab5687c93f because it stills breaks the LLDB tests. This was re-landed without addressing the issue or even agreement on how to address the issue. More details and discussion in https://reviews.llvm.org/D112374. | 3 年前 | |
[clangd] Avoid crash when printing call to string literal operator template Differential Revision: https://reviews.llvm.org/D132830 (cherry picked from commit 898c421975ed36b99ec2047589384539bd29a40b) | 3 年前 | |
Adds AST matcher for ObjCStringLiteral Differential Revision: https://reviews.llvm.org/D128103 | 3 年前 | |
Inline function calls. Fix unused variable in non-assert builds after 300fbf56f89aebbe2ef9ed490066bab23e5356d1 | 3 年前 | |
[clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to indicate that this feature is now supported on VLA vectors as well as VLS vectors. There is a complementary PR to the ACLE spec here https://github.com/ARM-software/acle/pull/213 Reviewed By: peterwaller-arm Differential Revision: https://reviews.llvm.org/D131573 (cherry picked from commit 13a784f368ef062a7bd652829bcf8bbdd94dc659) | 3 年前 | |
[clang][DebugInfo] Emit debuginfo for non-constant case value Currently, clang does not emit debuginfo for the switch stmt case value if it is an enum value. For example, $ cat test.c enum { AA = 1, BB = 2 }; int func1(int a) { switch(a) { case AA: return 10; case BB: return 11; default: break; } return 0; } $ llvm-dwarfdump test.o | grep AA $ Note that gcc does emit debuginfo for the same test case. This patch added such a support with similar implementation to CodeGenFunction::EmitDeclRefExprDbgValue(). With this patch, $ clang -g -c test.c $ llvm-dwarfdump test.o | grep AA DW_AT_name ("AA") $ Differential Revision: https://reviews.llvm.org/D134705 (cherry picked from commit 75be0482a2e2a78fae83f1ca604f4ee20d673796) | 3 年前 | |
[clang][NFC][AST] rename the ImportError to ASTImportError this patch is the continuation of my previous patch regarding the ImportError in ASTImportError.h Reviewed By: martong Differential Revision: https://reviews.llvm.org/D125340 | 3 年前 | |
[clang] Don't use Optional::hasValue (NFC) | 3 年前 | |
[clang][driver] Remove dynamic gcc-toolset/devtoolset logic This breaks when the newest available devtoolset directory is not a complete toolset: https://github.com/llvm/llvm-project/issues/57843 Remove this again in favor or just adding the two new directories for devtoolset/gcc-toolset 12. This reverts commit 35aaf548237a4f213ba9d95de53b33c5ce1eadce. This reverts commit 9f97720268911abae2ad9d90e270358db234a1c1. Fixes https://github.com/llvm/llvm-project/issues/57843 Differential Revision: https://reviews.llvm.org/D136435 | 3 年前 | |
Use any_of (NFC) | 3 年前 | |
[NFC] Start saving InstantiatedFromDecl in non-template functions In cases where a non-template function is defined inside a function template, we don't have information about the original uninstantiated version. In the case of concepts instantiation, we will need the ability to get back to the original template. This patch splits a piece of the deferred concepts instantaition patch off to accomplish the storage of this, with minor runtime overhead, and zero additional storage. | 3 年前 | |
[clang-format] Distinguish logical and after bracket from reference Fix commit b646f0955574 and remove redundant code. Differential Revision: https://reviews.llvm.org/D131750 (cherry picked from commit ef71383b0cfbacdbebf495015f6ead5294bf7759) | 3 年前 | |
[clang] Require strict matches for defines for PCH in GCC style directories When clang includes a PCH, it tolerates some amount of differences between the defines used when creating and when including the PCH - this seems to be intentionally allowed in c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in b63687519610a73dd565be1fec28332211b4df5b). When using a PCH (or when picking a PCH out of a directory containing multiple candidates) Clang used to accept the header if there were defines on the command line when creating the PCH that are missing when using the PCH, or vice versa, defines only set when using the PCH. The only cases where Clang explicitly rejected the use of a PCH is if there was an explicit conflict between the options, e.g. -DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO. The latter commit added a FIXME that we really should check whether mismatched defines actually were used somewhere in the PCH, so that the define would affect the outcome. This FIXME has stood unaddressed since 2012. This differs from GCC, which rejects PCH files if the defines differ at all. When explicitly including a single PCH file, the relaxed policy of allowing minor differences is harmless for correct use cases (but may fail to diagnose mismtaches), and potentially allow using PCHs in wider cases (where the user intentionally know that the differences in defines are harmless for the PCH). However, for GCC style PCH directories, with a directory containing multiple PCH variants and the compiler should pick the correct match out of them, Clang's relaxed logic was problematic. The directory could contain two otherwise identical PCHs, but one built with -DFOO and one without. When attempting to include a PCH and iterating over the candidates in the directory, Clang would essentially pick the first one out of the two, even if there existed a better, exact match in the directory. Keep the relaxed checking when specificlly including one named PCH file, but require strict matches when trying to pick the right candidate out of a GCC style directory with alternatives. This fixes https://github.com/lhmouse/mcfgthread/issues/63. Differential Revision: https://reviews.llvm.org/D126676 (cherry picked from commit c843c921a1a385bb805b2338d980436c94f83f19) | 3 年前 | |
[C++20][Modules][HU 1/5] Introduce header units as a module type. This is the first in a series of patches that introduce C++20 importable header units. These differ from clang header modules in that: (a) they are identifiable by an internal name (b) they represent the top level source for a single header - although that might include or import other headers. We name importable header units with the path by which they are specified (although that need not be the absolute path for the file). So "foo/bar.h" would have a name "foo/bar.h". Header units are made a separate module type so that we can deal with diagnosing places where they are permitted but a named module is not. Differential Revision: https://reviews.llvm.org/D121095 | 4 年前 | |
[X86] Add RDPRU instruction CPUID bit masks As mentioned on D128934 - we weren't including the CPUID bit handling for the RDPRU instruction AMD's APMv3 (24594) lists it as CPUID Fn8000_0008_EBX Bit#4 (cherry picked from commit 08a880509e4f7ca8d346dce42fe7528c3a33f22c) | 3 年前 | |
[AST] Improve traversal of concepts and concept requirements - Do not traverse concept decl inside AutoType. We only traverse declaration and definitions, not references to a declaration. - Do not visit implicit AST node the relevant traversal mode. - Add traversal extension points for concept requirements. - Renamed TraverseConceptReference to mark as helper to share the code. Having an extension point there seems confusing given that there are many concept refences in the AST that do not call the helper. Those are AutoType, AutoTypeLoc and constraint requirements. Only clangd code requires an update. There are no use-cases for concept requirement traversals yet, but I added them in the earlier version of the patch and decided to keep them for completeness. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D124532 | 4 年前 | |
[index-while-building] Fix build with -DBUILD_SHARED_LIBS=True The dependencies in clang/lib/IndexSerialization/CMakeLists.txt were incomplete, leading to link errors for a -DBUILD_SHARED_LIBS=True build. | 5 年前 | |
[clang] Remove unused forward declarations (NFC) | 3 年前 | |
[clang] Add __is_target_variant_{os,environment} builtins Xcode 13's clang has them. For the included testcase, Xcode's clang behaves like the implementation in this patch. Availability.h in the macOS 12.0 SDK (part of Xcode 13, and the current stable version of the macOS SDK) does something like: #if defined(__has_builtin) ... #if __has_builtin(__is_target_os) #if __has_builtin(__is_target_environment) #if __has_builtin(__is_target_variant_os) #if __has_builtin(__is_target_variant_environment) #if (... && ((__is_target_os(ios) && __is_target_environment(macabi)) || (__is_target_variant_os(ios) && __is_target_variant_environment(macabi)))) #define __OSX_AVAILABLE_STARTING(_osx, _ios) ... #define __OSX_AVAILABLE_BUT_DEPRECATED(_osxIntro, _osxDep, _iosIntro, _iosDep) ... #define __OSX_AVAILABLE_BUT_DEPRECATED_MSG(_osxIntro, _osxDep, _iosIntro, _iosDep, _msg) ... So if __has_builtin(__is_target_variant_os) or __has_builtin(__is_target_variant_environment) are false, these defines are not defined. Most of the time, this doesn't matter. But open-source clang currently fails to commpile a file containing only #include <Security/cssmtype.h> when building for catalyst by adding a -target arm64-apple-ios13.1-macabi triple, due to those __OSX_AVAILABLE macros not being set correctly. If a potential future SDK version were to include cssmtype.h transitively from a common header such as <Foundation/Foundation.h>, then it would become close to impossible to build Catalyst binaries with open-source clang. To fix this for normal catalyst builds, it's only necessary that __has_builtin() evaluates to true for these two built-ins -- the implementation of them doesn't matter. But as a courtesy, a correct (at least on the test cases I tried) implementation is provided. (This should also help people who try to build zippered code, where having the correct implementation does matter.) Differential Revision: https://reviews.llvm.org/D132754 | 3 年前 | |
[RISCV] Lazily add RVV C intrinsics. Leverage the method OpenCL uses that adds C intrinsics when the lookup failed. There is no need to define C intrinsics in the header file any more. It could help to avoid the large header file to speed up the compilation of RVV source code. Besides that, only the C intrinsics used by the users will be added into the declaration table. This patch is based on https://reviews.llvm.org/D103228 and inspired by OpenCL implementation. ### Experimental Results #### TL;DR: - Binary size of clang increase ~200k, which is +0.07% for debug build and +0.13% for release build. - Single file compilation speed up ~33x for debug build and ~8.5x for release build - Regression time reduce ~10% ( ninja check-all, enable all targets) #### Header size change | size | LoC | ------------------------------ Before | 4,434,725 | 69,749 | After | 6,140 | 162 | #### Single File Compilation Time Testcase: #include <riscv_vector.h> vint32m1_t test_vadd_vv_vfloat32m1_t(vint32m1_t op1, vint32m1_t op2, size_t vl) { return vadd(op1, op2, vl); } ##### Debug build: Before: real 0m19.352s user 0m19.252s sys 0m0.092s After: real 0m0.576s user 0m0.552s sys 0m0.024s ~33x speed up for debug build ##### Release build: Before: real 0m0.773s user 0m0.741s sys 0m0.032s After: real 0m0.092s user 0m0.080s sys 0m0.012s ~8.5x speed up for release build #### Regression time Note: the failed case is tools/llvm-debuginfod-find/debuginfod.test which is unrelated to this patch. ##### Debug build Before: Testing Time: 1358.38s Skipped : 11 Unsupported : 446 Passed : 75767 Expectedly Failed: 190 Failed : 1 After Testing Time: 1220.29s Skipped : 11 Unsupported : 446 Passed : 75767 Expectedly Failed: 190 Failed : 1 ##### Release build Before: Testing Time: 381.98s Skipped : 12 Unsupported : 1407 Passed : 74765 Expectedly Failed: 176 Failed : 1 After: Testing Time: 346.25s Skipped : 12 Unsupported : 1407 Passed : 74765 Expectedly Failed: 176 Failed : 1 #### Binary size of clang ##### Debug build Before text data bss dec hex filename 335261851 12726004 552812 348540667 14c64efb bin/clang After text data bss dec hex filename 335442803 12798708 552940 348794451 14ca2e53 bin/clang +253K, +0.07% code size ##### Release build Before text data bss dec hex filename 144123975 8374648 483140 152981763 91e5103 bin/clang After text data bss dec hex filename 144255762 8447296 483268 153186326 9217016 bin/clang +204K, +0.13% Authored-by: Kito Cheng <kito.cheng@sifive.com> Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com> Reviewed By: khchen, aaron.ballman Differential Revision: https://reviews.llvm.org/D111617 | 3 年前 | |
Add assert on End iteration distance to Rewriter::getRewrittenText. I currently have code that is crashing in the second std::advance call, and it was not straightforward to identify the problem, as the first line of the stacktrace is in RopePieceBTreeIterator::operator++: *** SIGILL; stack trace: *** PC: clang/include/clang/Rewrite/Core/RewriteRope.h:119 clang::RopePieceBTreeIterator::operator++() ../include/c++/v1/__iterator/advance.h:35 std::__u::__advance<>() ../include/c++/v1/__iterator/advance.h:65 std::__u::advance<>() clang/lib/Rewrite/Rewriter.cpp:228 clang::Rewriter::getRewrittenText() clang/include/clang/Rewrite/Core/Rewriter.h:106 clang::Rewriter::getRewrittenText() Adding an assertion produces a friendlier error message for the caller. Reviewed By: gribozavr2 Differential Revision: https://reviews.llvm.org/D117579 | 4 年前 | |
[clang][Sema] Fix a clang crash with btf_type_tag For the following program, $ cat t.c struct t { int (__attribute__((btf_type_tag("rcu"))) *f)(); int a; }; int foo(struct t *arg) { return arg->a; } Compiling with 'clang -g -O2 -S t.c' will cause a failure like below: clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc): Assertion Chunk.Kind == DeclaratorChunk::Paren' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: ...... #5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5) #6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79) #7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456) #8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0 #9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0 ...... The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example, the TypeLoc is BTFTagAttributedType 0x88614e0 'int btf_type_tag(rcu)()' sugar |-ParenType 0x8861480 'int ()' sugar | -FunctionNoProtoType 0x8861450 'int ()' cdecl | `-BuiltinType 0x87fd500 'int' while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and this will cause later assertion. To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in GetTypeSourceInfoForDeclarator(). Differential Revision: https://reviews.llvm.org/D136807 | 3 年前 | |
[clang] Require strict matches for defines for PCH in GCC style directories When clang includes a PCH, it tolerates some amount of differences between the defines used when creating and when including the PCH - this seems to be intentionally allowed in c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in b63687519610a73dd565be1fec28332211b4df5b). When using a PCH (or when picking a PCH out of a directory containing multiple candidates) Clang used to accept the header if there were defines on the command line when creating the PCH that are missing when using the PCH, or vice versa, defines only set when using the PCH. The only cases where Clang explicitly rejected the use of a PCH is if there was an explicit conflict between the options, e.g. -DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO. The latter commit added a FIXME that we really should check whether mismatched defines actually were used somewhere in the PCH, so that the define would affect the outcome. This FIXME has stood unaddressed since 2012. This differs from GCC, which rejects PCH files if the defines differ at all. When explicitly including a single PCH file, the relaxed policy of allowing minor differences is harmless for correct use cases (but may fail to diagnose mismtaches), and potentially allow using PCHs in wider cases (where the user intentionally know that the differences in defines are harmless for the PCH). However, for GCC style PCH directories, with a directory containing multiple PCH variants and the compiler should pick the correct match out of them, Clang's relaxed logic was problematic. The directory could contain two otherwise identical PCHs, but one built with -DFOO and one without. When attempting to include a PCH and iterating over the candidates in the directory, Clang would essentially pick the first one out of the two, even if there existed a better, exact match in the directory. Keep the relaxed checking when specificlly including one named PCH file, but require strict matches when trying to pick the right candidate out of a GCC style directory with alternatives. This fixes https://github.com/lhmouse/mcfgthread/issues/63. Differential Revision: https://reviews.llvm.org/D126676 (cherry picked from commit c843c921a1a385bb805b2338d980436c94f83f19) | 3 年前 | |
[analyzer] Improve loads from reinterpret-cast fields Consider this example: lang=C++ struct header { unsigned a : 1; unsigned b : 1; }; struct parse_t { unsigned bits0 : 1; unsigned bits2 : 2; // <-- header unsigned bits4 : 4; }; int parse(parse_t *p) { unsigned copy = p->bits2; clang_analyzer_dump(copy); // expected-warning@-1 {{reg_$1<unsigned int SymRegion{reg_$0<struct Bug_55934::parse_t * p>}.bits2>}} header *bits = (header *)© clang_analyzer_dump(bits->b); // <--- Was UndefinedVal previously. // expected-warning@-1 {{derived_$2{reg_$1<unsigned int SymRegion{reg_$0<struct Bug_55934::parse_t * p>}.bits2>,Element{copy,0 S64b,struct Bug_55934::header}.b}}} return bits->b; // no-warning: it's not UndefinedVal } bits->b should have the same content as the second bit of p->bits2 (assuming that the bitfields are in spelling order). --- The Store has the correct bindings. The problem is with the load of bits->b. It will eventually reach RegionStoreManager::getBindingForField() with Element{copy,0 S64b,struct header}.b, which is a FieldRegion. It did not find any direct bindings, so the getBindingForFieldOrElementCommon() gets called. That won't find any bindings, but it sees that the variable is on the //stack//, thus it must be an uninitialized local variable; thus it returns UndefinedVal. Instead of doing this, it should have created a //derived symbol// representing the slice of the region corresponding to the member. So, if the value of copy is reg1, then the value of bits->b should be derived{reg1, elem{copy,0, header}.b}. Actually, the getBindingForElement() already does exactly this for reinterpret-casts, so I decided to hoist that and reuse the logic. Fixes #55934 Reviewed By: martong Differential Revision: https://reviews.llvm.org/D128535 | 3 年前 | |
[RISCV][Clang] Refactor RISCVVEmitter. (NFC) Remove MaskedPrototype and add several fields in RVVIntrinsicRecord, compute Prototype in runtime. Reviewed By: rogfer01 Differential Revision: https://reviews.llvm.org/D126741 | 3 年前 | |
[include-cleaner] Include-cleaner library structure, and simplistic AST walking. Include-cleaner is a library that uses the clang AST and preprocessor to determine which headers are used. It will be used in clang-tidy, in clangd, in a standalone tool at least for testing, and in out-of-tree tools. Roughly, it walks the AST, finds referenced decls, maps these to used sourcelocations, then to FileEntrys, then matching these against #includes. However there are many wrinkles: dealing with macros, standard library symbols, umbrella headers, IWYU directives etc. It is not built on the C++20 modules concept of usage, to allow: - use with existing non-modules codebases - a flexible API embeddable in clang-tidy, clangd, and other tools - avoiding a chicken-and-egg problem where include cleanups are needed before modules can be adopted This library is based on existing functionality in clangd that provides an unused-include warning. However it has design changes: - it accommodates diagnosing missing includes too (this means tracking where references come from, not just the set of targets) - it more clearly separates the different mappings (symbol => location => header => include) for better testing - it handles special cases like standard library symbols and IWYU directives more elegantly by adding unified Location and Header types instead of side-tables - it will support some customization of policy where necessary (e.g. for style questions of what constitutes a use, or to allow both missing-include and unused-include modes to be conservative) This patch adds the basic directory structure under clang-tools-extra and a skeleton version of the AST traversal, which will be the central piece. A more end-to-end prototype is in https://reviews.llvm.org/D122677 RFC: https://discourse.llvm.org/t/rfc-lifting-include-cleaner-missing-unused-include-detection-out-of-clangd/61228 Differential Revision: https://reviews.llvm.org/D124164 | 4 年前 | |
[Syntax] avoid using c++17 features on 15.x branch | 3 年前 | |
[RISCV] Moving RVV intrinsic type related util to clang/Support We add a new clang library called clangSupport for putting those utils which can be used in clang table-gen and other clang component. We tried to put that into llvm/Support, but actually those stuffs only used in clang* and clang-tblgen, so I think that might be better to create clang/Support * clang will used that in https://reviews.llvm.org/D111617. Reviewed By: khchen, MaskRay, aaron.ballman Differential Revision: https://reviews.llvm.org/D121984 | 4 年前 |