TTom Stellard[clang][Sema] Fix a clang crash with btf_type_tag
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Strengthen -Wint-conversion to default to an error Clang has traditionally allowed C programs to implicitly convert integers to pointers and pointers to integers, despite it not being valid to do so except under special circumstances (like converting the integer 0, which is the null pointer constant, to a pointer). In C89, this would result in undefined behavior per 3.3.4, and in C99 this rule was strengthened to be a constraint violation instead. Constraint violations are most often handled as an error. This patch changes the warning to default to an error in all C modes (it is already an error in C++). This gives us better security posture by calling out potential programmer mistakes in code but still allows users who need this behavior to use -Wno-error=int-conversion to retain the warning behavior, or -Wno-int-conversion to silence the diagnostic entirely. Differential Revision: https://reviews.llvm.org/D129881 | 3 年前 | |
[CMake][Fuchsia] Enable assertions and backtraces in stage 1 build Differential Revision: https://reviews.llvm.org/D130514 | 3 年前 | |
[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-analyzer plugins require LLVM_ENABLE_PLUGINS also The clang-analyzer plugins are not linked to a particular tool, so they can only be compiled if plugins are broadly supported. We could opt instead to decide whether to link them to specifically against clang or with undefined symbols, depending on the value of LLVM_ENABLE_PLUGINS, but we do not currently expect there to be a use case for that rather niche configuration. Differential Revision: https://reviews.llvm.org/D119591 | 4 年前 | |
Downgrade implicit int and implicit function declaration to warning only The changes in Clang 15.0.0 which enabled these diagnostics as a warning which defaulted to an error caused disruption for people working on distributions such as Gentoo. There was an explicit request to downgrade these to be warning-only in Clang 15.0.1 with the expectation that Clang 16 will default the diagnostics to an error. See https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213 for more details on the discussion. See https://reviews.llvm.org/D133800 for the public review of these changes. | 3 年前 | |
[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 年前 | |
Fix running orc-rt tests with LLVM_BUILD_EXTERNAL_COMPILER_RT (again). Add missing dependency on lli when building compiler-rt with LLVM_BUILD_EXTERNAL_COMPILER_RT. Previously we would non-deterministically fail the tests due to the missing binary. This is essentially identical to 0e5ea403e8d, which added an earlier dependence on llvm-jitlink. rdar://96467892 | 3 年前 | |
[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 年前 | |
[NFC] Fix a misleading comment CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION | 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 年前 | |
[clang][SVE] Undefine preprocessor macro defined in arm_sve.h defines and uses __ai macro which needs to be undefined (as it is already in arm_neon.h). Reviewed By: paulwalker-arm Differential Revision: https://reviews.llvm.org/D131580 (cherry picked from commit 48e1250a91d244741c8677fed248ace1fcd7c41c) | 3 年前 | |
[clang] [docs] Update the changes of C++20 Modules in clang15 Since clang15 is going to be branched in July 26, and C++ modules still lack an update on ReleaseNotes. Although it is not complete yet, I think it would be better to add one since we've done many works for C++20 Modules in clang15. Differential Revision: https://reviews.llvm.org/D129138 | 3 年前 | |
Switch the default mode for clang-format to '-file'. Make 'LLVM' the fallback syntax used when we fail to find a '.clang-format' file. Adjust variable names appropriately. Update the editor integration pieces that specify a '-style' option to specify it as '-style=file'. I left the functionality in place because even if the preferred method is to use '.clang-format' files, this way if someone needs to clobber the style in their editor we show how to do so in these examples. Also check in a '.clang-format' file for Clang to ensure that separate checkouts and builds of Clang from LLVM can still get the nice formatting. =] This unfortunately required nuking the test for the absence of a '.clang-format' file as now the directory happening to be under your clang source tree will cause there to always be a file. ;] llvm-svn: 189741 | 12 年前 | |
.clang-tidy: Disable misc-no-recursion in general/across the monorepo | 4 年前 | |
Remove .gitignore entries not relevant in the monorepo. Differential Revision: https://reviews.llvm.org/D100049 | 5 年前 | |
SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION This reverts commit bc39d7bdd4977a953b2e102f8f7eb479ad78984e. rename CLANG_SONAME to LIBCLANG_SOVERSION [clang][cmake] introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION Differential Revision: https://reviews.llvm.org/D132486 | 3 年前 | |
Add myself as a code owner for SYCL support | 4 年前 | |
Honor system specific paths of MAN pages Summary: Caught on NetBSD. Patch by: Kamil Rytarowski (krytarowski) Reviewers: beanz, jroelofs Subscribers: cfe-commits, joerg Differential Revision: http://reviews.llvm.org/D14800 llvm-svn: 253693 | 10 年前 | |
Fix typos throughout the license files that somehow I and my reviewers all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended legacy anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731 | 7 年前 | |
Add a comment to indicate what this file is for. llvm-svn: 38533 | 18 年前 | |
PTH-- Remove feature entirely- When debugging a boost build with a modified version of Clang, I discovered that the PTH implementation stores TokenKind in 8 bits. However, we currently have 368 TokenKinds. The result is that the value gets truncated and the wrong token gets picked up when including PTH files. It seems that this will go wrong every time someone uses a token that uses the 9th bit. Upon asking on IRC, it was brought up that this was a highly experimental features that was considered a failure. I discovered via googling that BoostBuild (mostly Boost.Math) is the only user of this feature, using the CC1 flag directly. I believe that this can be transferred over to normal PCH with minimal effort: https://github.com/boostorg/build/issues/367 Based on advice on IRC and research showing that this is a nearly completely unused feature, this patch removes it entirely. Note: I considered leaving the build-flags in place and making them emit an error/warning, however since I've basically identified and warned the only user, it seemed better to just remove them. Differential Revision: https://reviews.llvm.org/D54547 Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9 llvm-svn: 348266 | 7 年前 | |
Replace links to archived mailing lists by links to Discourse forums | 4 年前 |
//===----------------------------------------------------------------------===// // C Language Family Front-end //===----------------------------------------------------------------------===//
Welcome to Clang. This is a compiler front-end for the C family of languages (C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM compiler infrastructure project.
Unlike many other compiler frontends, Clang is useful for a number of things beyond just compiling code: we intend for Clang to be host to a number of different source-level tools. One example of this is the Clang Static Analyzer.
If you're interested in more (including how to build Clang) it is best to read the relevant web sites. Here are some pointers:
Information on Clang: http://clang.llvm.org/ Building and using Clang: http://clang.llvm.org/get_started.html Clang Static Analyzer: http://clang-analyzer.llvm.org/ Information on the LLVM project: http://llvm.org/
If you have questions or comments about Clang, a great place to discuss them is on the Clang forums: https://discourse.llvm.org/c/clang/
If you find a bug in Clang, please file it in the LLVM bug tracker: http://llvm.org/bugs/