[PATCH] D56658: [MSP430] Add msp430 toochain

nathanchance added inline comments. Comment at: cfe/trunk/lib/CodeGen/CodeGenModule.cpp:141 + (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) { +fprintf(stderr, "TBAA enabled\n"); TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, getLa

[PATCH] D56658: [MSP430] Add msp430 toochain

nathanchance marked an inline comment as done. nathanchance added inline comments. Comment at: cfe/trunk/lib/CodeGen/CodeGenModule.cpp:141 + (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) { +fprintf(stderr, "TBAA enabled\n"); TBAA.reset(new Cod

[PATCH] D62445: [test] Fix plugin tests

nathanchance added inline comments. Comment at: cfe/trunk/lib/Analysis/plugins/CMakeLists.txt:1 +if(LLVM_ENABLE_PLUGINS) + add_subdirectory(SampleAnalyzer) I think this should have a dependency on `CLANG_ENABLE_STATIC_ANALYZER` like in `clang/test/CMakeLists.tx

[PATCH] D62873: Avoid building analyzer plugins if CLANG_ENABLE_STATIC_ANALYZER is OFF

nathanchance added a comment. Thanks for the quick fix, looks good to me! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62873/new/ https://reviews.llvm.org/D62873 ___ cfe-commits mailing list cfe-commits@lists.llvm.o

[PATCH] D65108: Reland "driver: Don't warn about assembler flags being unused when not assembling"

nathanchance added a comment. I tested this patch on top of r366728 and saw no regressions in my set of kernel builds. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65108/new/ https://reviews.llvm.org/D65108 ___ cfe-commits mailing list cf

[PATCH] D64527: driver: Don't warn about assembler flags being unused when not assembling

nathanchance added a comment. This change breaks building the Linux kernel for arm32 (at least): ... YACCscripts/dtc/dtc-parser.tab.c HOSTCC scripts/dtc/yamltree.o HOSTCC scripts/dtc/dtc-parser.tab.o HOSTCC scripts/dtc/dtc-lexer.lex.o HOSTLD scripts/dtc/dtc UPD

[PATCH] D77498: [Hexagon] Select lld as the default linker for linux-musl target

nathanchance added a comment. This does not take into account `CLANG_DEFAULT_LINKER`, resulting in a `check-clang` failure: $ cmake -GNinja \ -DCMAKE_C_COMPILER=clang \ -DCMAKE_CXX_COMPILER=clang++ \ -DLLVM_ENABLE_PROJECTS=clang \

[PATCH] D77498: [Hexagon] Select lld as the default linker for linux-musl target

nathanchance added a comment. > Weird -- the baseline didn't take CLANG_DEFAULT_LINKER into account either, > though, right? I assume by baseline you mean the test before this change? It does not seem like it. > Is it a regression? I guess not but the test is still broken when `CLANG_DEFAULT_

[PATCH] D77498: [Hexagon] Select lld as the default linker for linux-musl target

nathanchance added a comment. > These are new tests how do you get the generic lld driver to work? It doesn't, Clang invokes the appropriate driver in `ToolChain::GetLinkerPath()`: https://github.com/llvm/llvm-project/blob/6011627f5118dd64a0c33694b604c70e766d8c40/clang/lib/Driver/ToolChain.cpp#

[PATCH] D81390: [KernelAddressSanitizer] Make globals constructors compatible with kernel

nathanchance added a comment. I do not know enough about KASAN enough to review this patch but I can say that against mainline at https://git.kernel.org/linus/af7b4801030c07637840191c69eb666917e4135d, there appear to be no visible regressions with this version of the patch on top of caa2fddce7

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

nathanchance added a comment. Should dc969061c68e62328607d68215ed8b9ef4a1e4b1 be reverted as well? I just bisected an assertion failure while building the Linux kernel for arm64 to that change: clang: /home/nathan/cbl/src

[PATCH] D124159: [SimplifyCFG] Thread branches on same condition in more cases (PR54980)

nathanchance added a comment. I ended up reducing something down anyways. At the parent commit of dc969061c68e62328607d68215ed8b9ef4a1e4b1 , there is no crash. _Bool fpsimd_context_busy; enum { false, true } arch_static_b

[PATCH] D122189: [Clang][NeonEmitter] emit ret decl first for -Wdeclaration-after-statement

nathanchance added a comment. This passes through all my `ARCH=arm` and `ARCH=arm64` build and boot tests on `next-20220321` with the instances of `-Wdeclaration-after-statement` resolved and no new instances of any other warnings. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTI

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

nathanchance added a comment. The latest revision allows me to boot a kernel in QEMU now but that same kernel does not boot on bare metal. I'll see if I can narrow down the problematic translation unit with Nick's `subdir-ccflags-y` trick. Repository: rG LLVM Github Monorepo CHANGES SINCE L

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

nathanchance added a comment. This diff allows me to boot on bare metal as of v5.17-rc2: diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 6aef9ee28a39..8ee176dac669 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -125,6 +125,7 @@ obj-$(CONFI

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

nathanchance added a comment. In D110869#3295012 , @void wrote: > In D110869#3294696 , @nathanchance > wrote: > >> This diff allows me to boot on bare metal as of v5.17-rc2: >> >> diff --git a/arch/x86/kernel/M

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

nathanchance added a comment. It looks like `_paravirt_ident_64()` is the problematic function. This diff on top of v5.17-rc2 allows me to boot: diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c index 4420499f7bb4..c1b68504136c 100644 --- a/arch/x86/kernel/paravirt.c +

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

nathanchance added a comment. In D110869#3302625 , @nickdesaulniers wrote: > All built+boot. I know @nathanchance pointed out an issue with some already > complex code, but I'm of the opinion that fn should be attributed in kernel > sources. Aside fro

[PATCH] D129709: [clang][CodeGen] add fn_ret_thunk_extern to synthetic fns

nathanchance added a comment. This cleans up the objtool warnings I initially reported and does not introduce any other regressions in my Linux kernel build and QEMU boot tests. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129709/new/ https://rev

[PATCH] D124726: Suggest typoed directives in preprocessor conditionals

nathanchance added subscribers: nickdesaulniers, nathanchance. nathanchance added a comment. I see an instance of this warning in the Linux kernel due to the "Now, for unknown directives inside a skipped conditional block, we diagnose the unknown directive as a warning if it is sufficiently simi

[PATCH] D125506: [PowerPC] Implement XL compat __fnabs and __fnabss builtins.

nathanchance added subscribers: nickdesaulniers, nathanchance. nathanchance added a comment. I bisected a crash when compiling the Linux kernel to this change. A reduced C reproducer: enum { OP_CB_GETATTR = 3, OP_CB_RECALL, OP_CB_RECALL_ANY = 8, OP_CB_RECALL_SLOT = 10, OP_C

[PATCH] D156565: Diagnose use of VLAs in C++ by default

nathanchance added a comment. Is it expected that this introduces a warning for C code, as the commit message and tests appear to only affect C++? A trivial example from the Linux kernel: https://elixir.bootlin.com/linux/v6.5.8/source/tools/lib/bpf/btf_dump.c#L1678 #include #include #in

[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

nathanchance added a comment. This test case has never passed for me with `check-clang`, is there something environment related that is needed with this or are others experiencing this too? [147/148] Running the Clang regression tests llvm-lit: /home/nathan/cbl/git/tc-build/llvm-project/ll

[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

nathanchance added a comment. Done, thanks for looking into this! F9847579: check-time-trace-sections.json Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63325/new/ https://reviews.llvm.org/D63325

[PATCH] D63325: [Support][Time profiler] Make FE codegen blocks to be inside frontend blocks

nathanchance added a comment. > Could it be an issue with python? What is the version you are using? I would assume so... $ /usr/bin/python --version Python 3.7.4 Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63325/new/ https://reviews.llvm.org/D63325 ___

[PATCH] D66873: [Test][Time profiler] Fix test for python3

nathanchance added a comment. The test case passes for me after this, thanks for the fix! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66873/new/ https://reviews.llvm.org/D66873 ___ cfe-commits mailin

[PATCH] D66873: [Test][Time profiler] Fix test for python3

nathanchance accepted this revision. nathanchance added a comment. This revision is now accepted and ready to land. LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66873/new/ https://reviews.llvm.org/D66873 __

[PATCH] D66404: [CFG] Make destructor calls more accurate

nathanchance added a comment. This commit causes some warnings in the Linux kernel that appear to be false positives. For example: CC drivers/base/cpu.o drivers/base/cpu.c:404:1: error: control may reach end of non-void function [-Werror,-Wreturn-type] } ^ 1 error generated. C

[PATCH] D66404: [CFG] Make destructor calls more accurate

nathanchance added a comment. @NoQ thank you for the fix, I can confirm it works! Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D66404/new/ https://reviews.llvm.org/D66404 ___ cfe-commits mailing list cfe-commits@lists

[PATCH] D70919: [Hexagon] Avoid passing unsupported options to lld when -fuse-ld=lld is used

nathanchance added a comment. I am seeing the same failure that @leonardchan reported above. This is related to `-DCLANG_DEFAULT_LINKER=lld`: $ cmake -G Ninja \ -Wno-dev \ -DCMAKE_BUILD_TYPE=Release \ -DCLANG_DEFAULT_LINKER=lld \ -DPYTHON_EXECUTABLE=$(command -v

[PATCH] D72668: [Driver][test] Fix Driver/hexagon-toolchain-elf.c for -DCLANG_DEFAULT_LINKER=lld builds

nathanchance accepted this revision. nathanchance added a comment. This revision is now accepted and ready to land. This fixes the error for me and looks better from a documentation perspective. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72668/ne

[PATCH] D89158: [NewPM] Provide method to run all pipeline callbacks, used for -O0

nathanchance added a comment. $ cmake \ -G Ninja \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_C_COMPILER=$(command -v clang) \ -DCMAKE_CXX_COMPILER=$(command -v clang++) \ -DLLVM_CCACHE_BUILD=ON \ -DLLVM_ENABLE_PROJECTS="clang;polly" \ -DLLVM_TARGETS_TO_BUILD=X86 \ -DLLVM_USE_LINKER=$(

[PATCH] D91895: [Clang] improve -Wimplicit-fallthrough GCC compat

nathanchance added a comment. I think that not warning upon falling through to `goto` or `return` is a mistake. We have a confirmed case of a bug where `clang` would catch this bug whereas `gcc` would not: https://lore.kernel.org/lkml/20201121124019.21116-1-ogab...@kernel.org/. I suspect that

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

nathanchance added a comment. As far as I am aware, this iteration of the patch has no instances in the Linux kernel now. The instances I found with the first iteration of the patch only had a right hand side with side effects, not both sides, so this warning is effectively a no-op now (not tha

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

nathanchance added a comment. I can test this on the Linux kernel tonight and report the results tomorrow morning. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110656/new/ https://reviews.llvm.org/D110656

[PATCH] D110656: [clang][Sema] Warn on uninitialized array elments

nathanchance added a comment. In D110656#3034181 , @nathanchance wrote: > I can test this on the Linux kernel tonight and report the results tomorrow > morning. My apologies, I did not have time to get to this last night or today and I am going to be

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

nathanchance created this revision. nathanchance added reviewers: dblaikie, rsmith, nickdesaulniers. nathanchance requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. The Linux kernel has a macro called IS_ENABLED(), which evaluates to a constan

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

nathanchance added a comment. > In D107933#2942023 , @xbolva00 > wrote: > >> > > GCC does not warn (with common -Wall) for this case, right? I think Clang > should not as well. Correct, GCC does not warn at all about unreachable fallthrough annotations

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

nathanchance added a comment. So something more along the lines of diff diff --git a/clang/include/clang/Basic/DiagnosticGroups.td b/clang/include/clang/Basic/DiagnosticGroups.td index 1555a9ee2465..0aa9a82e3d11 100644 --- a/clang/include/clang/Basic/DiagnosticGroups.td +++ b/clang/inc

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

nathanchance added a comment. With several Linux kernel `defconfig` builds, I see the following instances of the warning: drivers/net/wireless/intel/iwlwifi/mvm/scan.c:835:3: warning: bitwise and of boolean expressions; did you mean logical and? [-Wbool-operation-and] drivers/staging/rtl819

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

nathanchance added a comment. In D107933#2942430 , @xbolva00 wrote: > Yes, something like that, plus I think you want put > UnreachableCodeFallthrough into group UnreachableCode as well. So you would recommend adding it to `UnreachableCode` rather than

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

nathanchance added a comment. In D108003#2944413 , @Quuxplusone wrote: > FWIW, all three of @nathanchance's detected lines look like good true > positives to me: even if they're not //bugs//, they all look like places the > programmer //meant// to writ

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

nathanchance updated this revision to Diff 366363. nathanchance added a comment. - -Wimplicit-fallthrough-unreachable -> -Wunreachable-code-fallthrough, enabled under -Wunreachable-code (Dávid, Aaron). - Drop "case 225" from new test, as it does not add to test coverage (Nick). - Add -Wunreacha

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

nathanchance marked an inline comment as done. nathanchance added inline comments. Comment at: clang/test/SemaCXX/switch-implicit-fallthrough.cpp:211-214 +case 224: + n += 400; +case 225: // expected-warning{{unannotated fall-through between switch labels}} expected

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

nathanchance added a comment. I have sent the following patches for the Linux kernel. These were the only instances of the warning that I found across the code base in all of the configurations that we usually test so thank you for the heads up so I could send fixes before this lands. https://

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

nathanchance updated this revision to Diff 366733. nathanchance marked an inline comment as not done. nathanchance edited the summary of this revision. nathanchance added a comment. - Update commit message (forgot to use `arc diff --edit --verbatim`) [David] Repository: rG LLVM Github Monorepo

[PATCH] D107933: [clang] Expose unreachable fallthrough annotation warning

This revision was automatically updated to reflect the committed changes. Closed by commit rG9ed4a94d6451: [clang] Expose unreachable fallthrough annotation warning (authored by nathanchance). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D107933/new/

[PATCH] D110869: [X86] Implement -fzero-call-used-regs option

nathanchance added a comment. `check-llvm` does not pass with this revision nor does it resolve the boot failure that Nick mentioned, just in case that was the intention of the revision :) I ran the kernel through `gdb` and it still does not appear to get to `start_kernel`. Repository: rG L

[PATCH] D112600: [ARM] Use hardware TLS register in Thumb2 mode when -mtp=cp15 is passed

nathanchance added a subscriber: peter.smith. nathanchance added a comment. I tested this against `next-20211027`, where it resolved the build error and boots in QEMU master without any visible issues. Disassembly between GCC and clang seems to be good. I'll leave it up to @nickdesaulniers and @

[PATCH] D111199: [Clang][LLVM][Attr] support btf_type_tag attribute

nathanchance added a comment. I bisected a crash in the Linux kernel down to the reland commit (and it is not fixed as of https://github.com/llvm/llvm-project/commit/2249ecee8d9a6237f51485bd39f01ba031575987): $ git bisect log # bad: [bdaa181007a46d317a1665acb8234eddeee82815] [TwoAddressInst

[PATCH] D105169: [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

nathanchance added a comment. Prior to the latest revert (fd9b099906c61e46574d1ea2d99b973321fe1d21 ), the Linux kernel's binary verifier (`objtool`) points out an issue when building with ThinLTO and `-fsanitize=integer-divide

[PATCH] D114848: [Analysis] Ignore casts and unary ops for uninitialized values

nathanchance added a comment. I tested the problematic Linux kernel configuration that uncovered this issue with this patch and the issue was resolved. I tested an x86_64 allmodconfig build and did not see any warnings. Comment at: clang/lib/Analysis/UninitializedValues.cpp:5

[PATCH] D130586: [cmake] Use `CMAKE_INSTALL_LIBDIR` too

nathanchance added a comment. I can no longer do a two stage build on Fedora after this change. $ cmake \ -B build/stage1 \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_C_COMPILER=$(command -v clang) \ -DCMAKE_CXX_COMPILER=$(command -v clang++) \ -DLLVM_ENABLE_PROJECTS="clang;lld" \ -DLLVM_

[PATCH] D134461: [Clang] Warn when trying to deferencing void pointers in C

nathanchance added subscribers: nickdesaulniers, nathanchance. nathanchance added a comment. This warning is quite noisy for the Linux kernel due to a couple of places where a `void *` is dereferenced as part of compile time checking. My original commentary is available on our GitHub issue track

[PATCH] D134461: [Clang] Warn when trying to deferencing void pointers in C

nathanchance added a comment. In D134461#3815458 , @aaron.ballman wrote: > What do folks think of that idea? I think that all sounds reasonable to me (although I am far from an authority on these matters). As far as I understand it, the kernel cannot u

[PATCH] D133574: [C2x] reject type definitions in offsetof

nathanchance added a comment. In D133574#3815951 , @aaron.ballman wrote: > LGTM, thank you! Please don't land until you have some indication from the > kernel folks that this won't be super disruptive for them. CC > @nickdesaulniers and @nathanchance f

[PATCH] D133574: [C2x] reject type definitions in offsetof

nathanchance added a comment. Diff 463063 looks good against the Linux kernel with https://lore.kernel.org/20220925153151.2467884-1...@inclyc.cn/ applied. I see no additional errors/warnings and the `drivers/media/platform/nvidia/tegra-vde/v4l2.c` did disappear. Once that patch has been fully

[PATCH] D134702: [Clang] Don't warn if deferencing void pointers in unevaluated context

nathanchance added a comment. Thanks a lot for fixing this! I took it for a spin against the Linux kernel and all instances of `-Wvoid-ptr-dereference` disappeared :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134702/new/ https://reviews.llvm.o

[PATCH] D134831: [Clang][Sema] Add -Wcast-function-type-strict

nathanchance added inline comments. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8686 +def warn_cast_function_type_strict : Warning, + InGroup, DefaultIgnore; def err_cast_pointer_to_non_pointer_int : Error< kees wrote: > aaron.ballman wrote: >

[PATCH] D134831: [Clang][Sema] Add -Wcast-function-type-strict

nathanchance added a comment. In D134831#3827790 , @samitolvanen wrote: > In D134831#3827730 , > @nickdesaulniers wrote: > >> Please get the patch disabling this warning for the kernel in flight before >> landi

[PATCH] D134671: [Driver] Prevent Mips specific code from claiming -mabi argument on other targets.

nathanchance added a comment. In D134671#3828197 , @craig.topper wrote: > In D134671#3824644 , > @nickdesaulniers wrote: > >> I don't think it's an issue for us to work around downstream, but this did >> regres

[PATCH] D140270: MIPS: fix build from IR files, nan2008 and FpAbi

nathanchance added a comment. This does not show any issues with any of the MIPS configurations that I build in the Linux kernel, thanks for fixing the problems I reported! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D140270/new/ https://reviews.

[PATCH] D136790: [Clang][Sema] Add -Wincompatible-function-pointer-types-strict

nathanchance added inline comments. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8217 + err_typecheck_convert_incompatible_function_pointer.Text>, + InGroup>, DefaultIgnore; def ext_typecheck_convert_discards_qualifiers : ExtWarn< aaron.ballma

[PATCH] D136790: [Clang][Sema] Add -Wincompatible-function-pointer-types-strict

nathanchance added inline comments. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8217 + err_typecheck_convert_incompatible_function_pointer.Text>, + InGroup>, DefaultIgnore; def ext_typecheck_convert_discards_qualifiers : ExtWarn< aaron.ballma

[PATCH] D136790: [Clang][Sema] Add -Wincompatible-function-pointer-types-strict

nathanchance added inline comments. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8217 + err_typecheck_convert_incompatible_function_pointer.Text>, + InGroup>, DefaultIgnore; def ext_typecheck_convert_discards_qualifiers : ExtWarn< samitolvanen

[PATCH] D140270: MIPS: fix build from IR files, nan2008 and FpAbi

nathanchance added a comment. I tested this against the kernel and left my feedback above (no issues) so this can be merged. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D140270/new/ https://reviews.llvm.org/D140270 __

[PATCH] D139114: [Clang][Sema] Enabled implicit conversion warning for CompoundAssignment operator.

nathanchance added a comment. For what it’s worth, this triggers a LOT in the Linux kernel for the pattern that @MaskRay pointed out: https://gist.github.com/nathanchance/a76c2ba0a22dda3251c4ec5ee9e3f285 $ rg -c -- -Wconstant-conversion $TMP_FOLDER/4c37671a7c946ac246b52fa44a6a649b89d6310b-bu

[PATCH] D139114: [Clang][Sema] Enabled implicit conversion warning for CompoundAssignment operator.

nathanchance added a comment. > In D139114#4053166 , @nathanchance > wrote: > >> For what it’s worth, this triggers a LOT in the Linux kernel for the pattern >> that @MaskRay pointed out: > > Out of curiosity, has it found any true positives that you can

[PATCH] D139114: [Clang][Sema] Enabled implicit conversion warning for CompoundAssignment operator.

nathanchance added a comment. > I’ll have to filter the warnings to see if there are any other instances with > other operators that appear problematic. I count a single warning that triggers for an arithmetic operator (which might be a bug): ../drivers/net/wireless/ralink/rt2x00/rt2800lib.c

[PATCH] D125506: [PowerPC] Implement XL compat __fnabs and __fnabss builtins.

nathanchance added a comment. @amyk Thank you a lot for the fix! I'll pull it down and verify everything is fixed tonight. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125506/new/ https://reviews.llvm.org/D125506

[PATCH] D142609: [Clang] Fix -Wconstant-logical-operand when LHS is a constant

nathanchance added a comment. I took the most recent version for a spin against the Linux kernel. The couple of issues that a previous revision of the warning flagged (https://github.com/ClangBuiltLinux/linux/issues/1806, https://github.com/ClangBuiltLinux/linux/issues/1807) are no longer visib

[PATCH] D142609: [Clang] Fix -Wconstant-logical-operand when LHS is a constant

nathanchance added a comment. In D142609#4511579 , @nickdesaulniers wrote: > In D142609#4507696 , @nathanchance > wrote: > >> but I see a new one along a similar line as those: >> >> https://elixir.bootlin.com/l

[PATCH] D142609: [Clang] Fix -Wconstant-logical-operand when LHS is a constant

nathanchance added a comment. For the record, I have sent https://lore.kernel.org/20230718-nsecs_to_jiffies_timeout-constant-logical-operand-v1-0-36ed8fc8f...@kernel.org/ to address those warnings for the kernel. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://review

[PATCH] D155342: [clang][JumpDiagnostics] ignore non-asm goto target scopes

nathanchance added a comment. Thanks, I can confirm that the `__attribute__((__cleanup__(...)))` errors that we observed with Peter's work-in-progress guards series are resolved and that all the errors I observed when building the kernel after https://reviews.llvm.org/D154696 was merged are no

[PATCH] D154696: [Clang] Diagnose jumps into statement expressions

nathanchance added a comment. The error added by this patch triggers on some recently added code to the Linux kernel's -next tree, which I failed to test above due to its generally unstable nature: drivers/gpu/drm/tests/drm_exec_test.c:41:3: error: cannot jump from this indirect goto stateme

[PATCH] D154696: [Clang] Diagnose jumps into statement expressions

nathanchance added a comment. In D154696#4525254 , @cor3ntin wrote: > Can you let me know what the linux folks think? Thanks a lot! Sure thing, you should be able to follow along on the web as well: https://lore.kernel.org/2023070637.GA138486@dev-ar

[PATCH] D76096: [clang] allow const structs/unions/arrays to be constant expressions for C

nathanchance added a comment. In D76096#4564855 , @DavidSpickett wrote: > One of the kernel tests now fails to build for AArch64 and Arm: > > 00:00:48 ++ make > CC=/home/tcwg-buildslave/workspace/tcwg_kernel_0/bin/aarch64-cc > LD=/home/tcwg-buildslave

[PATCH] D157435: [Sema] Do not emit -Wmissing-variable-declarations for register variables

nathanchance created this revision. nathanchance added reviewers: aaron.ballman, nickdesaulniers. Herald added a subscriber: pengfei. Herald added a project: All. nathanchance requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. When building th

[PATCH] D157435: [Sema] Do not emit -Wmissing-variable-declarations for register variables

nathanchance updated this revision to Diff 548337. nathanchance added a comment. - Update formatting in release notes - Add GCC bug link to commit message - Remove unnecessary REQUIRES: in test Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157435/ne

[PATCH] D157435: [Sema] Do not emit -Wmissing-variable-declarations for register variables

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGa22d385f9656: [Sema] Do not emit -Wmissing-variable-declarations for register variables (authored by nathanchance). Repository: rG LLVM Github Mo

[PATCH] D154696: [Clang] Diagnose jumps into statement expressions

nathanchance added subscribers: nickdesaulniers, nathanchance. nathanchance added a comment. This patch breaks building the Linux kernel for PowerPC, which uses `asm goto` with a local label in a statement expression for the WARN macro. It seems like something with the scoping is going wrong. I

[PATCH] D153989: [compiler-rt] Move crt into builtins

nathanchance added a comment. This change appears to break `-DCOMPILER_RT_BUILD_CRT=OFF`: $ cmake -B build -S llvm -DCMAKE_BUILD_TYPE=Release -DCOMPILER_RT_BUILD_CRT=OFF -DLLVM_ENABLE_PROJECTS='clang;compiler-rt;lld' ... CMake Error at cmake/modules/AddLLVM.cmake:1935 (add_dependencies):

[PATCH] D154696: [Clang] Diagnose jumps into statement expressions

nathanchance added a comment. In D154696#4494899 , @cor3ntin wrote: > The issue is that `VerifyIndirectOrAsmJumps` does not consider that label > may be local label at all, I'm not exactly sure how to improve that. > The fact it works currently seems ki

[PATCH] D154696: [Clang] Diagnose jumps into statement expressions

nathanchance added a comment. I suspect this is the same issue but our CI pointed out another instance of this error in some x86 code (https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2SW8BY7moEweMJC6DJpzidlGYt8/build.log), which does not appear to use local la

[PATCH] D72231: [Sema] Adds the pointer-to-int-cast diagnostic

nathanchance added a comment. In D72231#1881855 , @rjmccall wrote: > In D72231#1881797 , @nickdesaulniers > wrote: > > > In D72231#1881784 , @rjmccall > > wrote: > > > > >

[PATCH] D75563: [clang][Parse] properly parse asm-qualifiers, asm inline

nathanchance added inline comments. Comment at: clang/test/Parser/asm-qualifiers.c:20 + +void combinations(void) { + asm volatile inline(""); I'm probably being dense but what is intended to be tested differently between `combinations` and `permutations`? I ass

[PATCH] D75563: [clang][Parse] properly parse asm-qualifiers, asm inline

nathanchance added inline comments. Comment at: clang/test/Parser/asm-qualifiers.c:20 + +void combinations(void) { + asm volatile inline(""); nickdesaulniers wrote: > nathanchance wrote: > > I'm probably being dense but what is intended to be tested differently

[PATCH] D70638: [Diagnostic] add a warning which warns about misleading indentation

nathanchance added a comment. As an FYI, this appears to cause several false positive warnings with the Linux kernel: ../drivers/video/fbdev/core/fbmem.c:665:3: warning: misleading indentation; statement is not part of the previous 'else' [-Wmisleading-indentation] if (fb_logo.depth

[PATCH] D70638: [Diagnostic] add a warning which warns about misleading indentation

nathanchance added a comment. > IMO that is misleading indentation. A single space followed by a tab? WTF I guess I will take a look over all of the warnings that cropped up and see if this is the case for all of them. If it is, I will just send patches to fix those (with the justification of t

[PATCH] D70638: [Diagnostic] add a warning which warns about misleading indentation

nathanchance added a comment. As a follow up to my previous post, I have sent patches to clean up all of the warnings that I see in the Linux kernel. However, I found one that I do believe is a false positive: ../drivers/staging/uwb/allocator.c:353:3: warning: misleading indentation; stateme

[PATCH] D75758: [Sema] Add -Wpointer-to-enum-cast and -Wvoid-pointer-to-enum-cast

nathanchance created this revision. nathanchance added reviewers: Mordante, rjmccall. Herald added a project: clang. GCC does not warn on casts from pointers to enumerators, while clang currently does: https://godbolt.org/z/3DFDVG This causes a bunch of extra warnings in the Linux kernel, where c

[PATCH] D75758: [Sema] Add -Wpointer-to-enum-cast and -Wvoid-pointer-to-enum-cast

nathanchance updated this revision to Diff 248824. nathanchance edited the summary of this revision. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75758/new/ https://reviews.llvm.org/D75758 Files: clang/include/clang/Basic/DiagnosticGroups.td cl

[PATCH] D75758: [Sema] Add -Wpointer-to-enum-cast and -Wvoid-pointer-to-enum-cast

nathanchance marked 2 inline comments as done. nathanchance added inline comments. Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3673 +def warn_pointer_to_enum_cast : Warning< + "cast to smaller integer type %1 from %0">, + InGroup; xbolva00 wrot

[PATCH] D75758: [Sema] Add -Wpointer-to-enum-cast and -Wvoid-pointer-to-enum-cast

nathanchance marked an inline comment as done. nathanchance added a comment. Thanks for the review and accepting. I do not have commit rights, would you mind doing that on my behalf? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75758/new/ https:/

[PATCH] D72231: [Sema] Adds the pointer-to-int-cast diagnostic

nathanchance added a comment. There appear to a be semantic difference between GCC and clang with the current version of this patch which results in a lot of additional warnings in the Linux kernel: https://godbolt.org/z/eHFJd8 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D72231: [Sema] Adds the pointer-to-int-cast diagnostic

nathanchance added a comment. In D72231#1879347 , @rjmccall wrote: > Warning about casting to an enum seems clearly correct and in scope for this > warning. Warning about casting to `_Bool` seems clearly incorrect and should > not be warned about at all

[PATCH] D144967: [PowerPC] Recognize long CPU name for -mtune in Clang

nathanchance added a comment. Thanks for the fix, it appears to work fine for me against the kernel's `powernv_defconfig` target. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144967/new/ https://reviews.llvm.org/D144967 _

[PATCH] D144967: [PowerPC] Recognize long CPU name for -mtune in Clang

nathanchance added a comment. Could this be merged into `main` and backported to `release/16.x`? If this makes 16.0.0 final, I think the kernel can avoid working around this issue altogether, as `-mtune` was only wired up to do something on PowerPC in during the 16 development cycle; in prior v

[PATCH] D144967: [PowerPC] Recognize long CPU name for -mtune in Clang

nathanchance added a comment. @amyk thank you so much! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144967/new/ https://reviews.llvm.org/D144967 ___ cfe-commits mailing list cfe-commits@lists.llvm.org h

[PATCH] D144654: [Lex] Warn when defining or undefining any builtin macro

nathanchance added subscribers: nickdesaulniers, nathanchance. nathanchance added a comment. For what it's worth, this change is quite noisy for the Linux kernel, as there are certain macros undefined in header files that are included in many other headers. Additionally, at least one new instanc

  1   2   >