[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,

[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

[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

[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

[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] 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.

[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

[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

[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 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] 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:

[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] 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

[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

[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

[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;

[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

[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] 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

[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] 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] 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

[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

[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

[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

[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

[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()`:

[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

[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/

[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

[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] 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 \

[PATCH] D94355: [Passes] Add relative lookup table converter pass

nathanchance added a comment. This patch breaks a two stage build with LTO: $ git bisect log # bad: [f0bc2782f281ca05221d2f1735bbaff6c4b81ebb] [TTI] NFC: Remove unused 'OptSize' parameter from shouldMaximizeVectorBandwidth # good: [9829f5e6b1bca9b61efc629770d28bb9014dec45] [CVP]

[PATCH] D94355: [Passes] Add relative lookup table converter pass

nathanchance added a comment. In D94355#2717813 , @gulfem wrote: > Thanks for the report @nathanchance, and I'm looking at it now. Thanks! > Is this failure from one of the bots? No, this was discovered by a user of my LLVM build script:

[PATCH] D94355: [Passes] Add relative lookup table converter pass

nathanchance added a comment. In D94355#2717958 , @gulfem wrote: > @nathanchance do you prefer me to revert the patch first as it might take me > a while to investigate it? > Btw, I was able to reproduce the issue by following your steps. I would say if

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

nathanchance added a comment. In D100581#2721430 , @nickdesaulniers wrote: > Huh, maybe not: https://godbolt.org/z/PnE1fMGWo This difference has caused some confusion already for the Linux kernel:

[PATCH] D99220: [RISCV] Fix mcount name

nathanchance created this revision. Herald added subscribers: vkmr, frasercrmck, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal,

[PATCH] D98881: [RISCV] Fix mcount name

nathanchance updated this revision to Diff 332811. nathanchance retitled this revision from "[RISCV] Fix mcount name for Linux" to "[RISCV] Fix mcount name". nathanchance edited the summary of this revision. nathanchance added a comment. Herald added subscribers: frasercrmck, apazos, jocewei,

[PATCH] D98881: [RISCV] Fix mcount name

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGef58ae86ba77: [RISCV] Fix mcount name (authored by nathanchance). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D98881: [RISCV] Fix mcount name

nathanchance updated this revision to Diff 333185. nathanchance added a comment. Drop "riscv32" and "riscv64" from list of checked triples (thanks to Fangrui for catching it with a good explanation). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D98881: [RISCV] Fix mcount name for Linux

nathanchance added a comment. Would it be better to hoist it into `RISCVTargetInfo` and modify the BSD switch statements to respect that in their respective TargetInfo constructors? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98881/new/

[PATCH] D98881: [RISCV] Fix mcount name for Linux

nathanchance created this revision. Herald added subscribers: vkmr, evandro, luismarques, sameer.abuasal, s.egerton, Jim, benna, psnobl, PkmX, rogfer01, shiva0217, kito-cheng, simoncook. nathanchance requested review of this revision. Herald added a project: clang. Herald added a subscriber:

[PATCH] D98881: [RISCV] Fix mcount name for Linux

nathanchance added a comment. Such a diff does not look too bad: diff --git a/clang/lib/Basic/Targets/OSTargets.h b/clang/lib/Basic/Targets/OSTargets.h index 539466c4f678..c32972c1e04e 100644 --- a/clang/lib/Basic/Targets/OSTargets.h +++ b/clang/lib/Basic/Targets/OSTargets.h @@ -256,6

[PATCH] D93164: [AST] Add generator for source location introspection

nathanchance added a comment. I am seeing a spew of errors after 19740652c4c4329e2b9e77f96e5e31c360b4e8bb (what appears to be the latest version of this patch): $ cmake \ -G Ninja \ -DCMAKE_BUILD_TYPE=Release \

[PATCH] D93164: [AST] Add generator for source location introspection

nathanchance added a comment. In D93164#2630534 , @steveire wrote: > In D93164#2630203 , @nathanchance > wrote: > >> I am seeing a spew of errors after 19740652c4c4329e2b9e77f96e5e31c360b4e8bb >>

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

nathanchance added a comment. I am still running a series of builds against the Linux kernel but I already see one instance of this warning where the suggestion would change the meaning of the code in an incorrect way: drivers/input/touchscreen.c:81:17: warning: use of bitwise '|' with

[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]

[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] 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

[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}}

[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

[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

[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.

[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

[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 +++

[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

[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

[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

[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] D116128: [clang][driver] Warn when '-mno-outline-atomics' is used with a non-AArch64 triple

nathanchance updated this revision to Diff 395879. nathanchance added a comment. Herald added subscribers: luke957, s.egerton, simoncook. - Move test from x86-outline-atomics.c to unsupported-outline-atomics.c (Marco). - Add a test for riscv64 to ensure it works with multiple architectures

[PATCH] D116128: [clang][driver] Warn when '-mno-outline-atomics' is used with a non-AArch64 triple

nathanchance created this revision. nathanchance added reviewers: melver, nickdesaulniers, t.p.northover. Herald added subscribers: pengfei, kristof.beyls. nathanchance requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. The Linux kernel has a

[PATCH] D116128: [clang][driver] Warn when '-mno-outline-atomics' is used with a non-AArch64 triple

nathanchance added inline comments. Comment at: clang/test/Driver/x86-outline-atomics.c:1-7 +// RUN: %clang -target x86_64 -moutline-atomics -S %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OUTLINE-ATOMICS +// CHECK-OUTLINE-ATOMICS: warning: 'x86_64' does not support

[PATCH] D116128: [clang][driver] Warn when '-mno-outline-atomics' is used with a non-AArch64 triple

nathanchance added a comment. If there are more qualified people to review and accept this, please add them, I was unsure of who else to add. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116128/new/ https://reviews.llvm.org/D116128

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

nathanchance added a comment. @hyeongyukim I hand reduced a couple of the translation units that I see issues in so apologies if they are a little verbose. The full set of warnings: drivers/net/ethernet/renesas/ravb.lto.o: warning: objtool: .text.ravb_set_gti: unexpected end of section

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

nathanchance added a comment. @hyeongyukim I am currently offline for the evening but it seems like my reduction might have been too aggressive. It looks like this code comes from `ravb_set_gti()`

[PATCH] D116128: [clang][driver] Warn when '-mno-outline-atomics' is used with a non-AArch64 triple

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGbe8180af5854: [clang][driver] Warn when -mno-outline-atomics is used with a non-AArch64… (authored by nathanchance). Repository: rG LLVM Github

[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

[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

[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]

[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] 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:

[PATCH] D116059: [Clang][CFG] check children statements of asm goto

nathanchance added a comment. The two false positive warnings in the kernel are fixed with this patch and there were no new warnings introduced. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D116059/new/ https://reviews.llvm.org/D116059

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

nathanchance added a comment. In D105169#3236484 , @hyeongyukim wrote: > @nathanchance > > I tried to reproduce the last warning (intelfbhw_validate_mode), but I failed > to produce it. > I think my reproducer is correct, but it does not make any

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

nathanchance added a comment. In D105169#3246378 , @nlopes wrote: > In D105169#3244624 , @nathanchance > wrote: > >> I can reduce all of these down for you and/or I can start an email thread >> with the

[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

[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

[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 @@

[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

[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] D117717: [clang] Ignore -fconserve-stack

nathanchance abandoned this revision. nathanchance added a comment. As discussed, this is not the right fix for the issue. I have just gone ahead and told the original reporter to use `scan-build` with the `--use-cc=clang` flag to avoid these issues. Repository: rG LLVM Github Monorepo

[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

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

nathanchance added a subscriber: nickdesaulniers. nathanchance added a comment. In D105169#3242949 , @hyeongyukim wrote: > @nathanchance Hi, I analyzed all four warnings. Thanks a lot for doing this! > Warning #1: can be handled by x86-backend. filled

[PATCH] D117717: [clang] Ignore -fconserve-stack

nathanchance created this revision. nathanchance added reviewers: aaron.ballman, MaskRay, srhines. Herald added a subscriber: dang. nathanchance requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. This flag is used when building the Linux

[PATCH] D117717: [clang] Ignore -fconserve-stack

nathanchance added a comment. In D117717#3256180 , @MaskRay wrote: > Clang has a long list of ignored options but most were added during the > catch-up phase when Clang strove to be a competitor compiler. > I think for new ignored options there needs to

[PATCH] D117717: [clang] Ignore -fconserve-stack

nathanchance added a comment. In D117717#3256293 , @MaskRay wrote: > Assuming scan-build is clang/tools/scan-build, which is in tree and can be > fixed instead. Yes, that is the one. > I am not familiar with it, but from > >> However, this caused

[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

[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,

[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] 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

[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:

[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 }

[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/

[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" \

[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

[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/

[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

[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

  1   2   >