On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < llvm-dev at lists.llvm.org> wrote:> As an update, after lots of fixes from a number of different people > (thanks everyone!), the current list of false-positives on `ninja > check-llvm` for the more stringent Gotcha A diagnostic is: > > LLVM :: Analysis/CostModel/X86/vselect-cost.ll > LLVM :: CodeGen/AMDGPU/GlobalISel/smrd.ll > LLVM :: CodeGen/AMDGPU/fp_to_uint.ll > LLVM :: CodeGen/AMDGPU/global-constant.ll > LLVM :: CodeGen/AMDGPU/merge-tbuffer.mir > LLVM :: CodeGen/AMDGPU/smrd.ll > LLVM :: CodeGen/AMDGPU/unhandled-loop-condition-assertion.ll > LLVM :: CodeGen/ARM/build-attributes.ll > LLVM :: CodeGen/ARM/float-helpers.s > LLVM :: CodeGen/ARM/select-imm.ll > LLVM :: CodeGen/ARM/struct_byval_arm_t1_t2.ll > LLVM :: CodeGen/Mips/cconv/arguments-float.ll > LLVM :: CodeGen/Mips/cconv/arguments-hard-float-varargs.ll > LLVM :: CodeGen/Mips/cconv/arguments-hard-float.ll > LLVM :: CodeGen/Mips/cconv/arguments-varargs.ll > LLVM :: CodeGen/Mips/cconv/arguments.ll > LLVM :: CodeGen/Mips/cconv/return-hard-fp128.ll > LLVM :: CodeGen/Mips/cconv/return-hard-struct-f128.ll > LLVM :: CodeGen/Mips/ci2.ll > LLVM :: CodeGen/Mips/countleading.ll > LLVM :: CodeGen/Mips/divrem.ll > LLVM :: CodeGen/Mips/dynamic-stack-realignment.ll > LLVM :: CodeGen/Mips/inlineasm-operand-code.ll > LLVM :: CodeGen/Mips/mips64muldiv.ll > LLVM :: CodeGen/PowerPC/ppc64-crsave.mir > LLVM :: CodeGen/X86/avx-cast.ll > LLVM :: CodeGen/X86/fp-intrinsics.ll > LLVM :: CodeGen/X86/splat-for-size.ll > LLVM :: CodeGen/X86/sse-scalar-fp-arith.ll > LLVM :: CodeGen/X86/vec_shift6.ll > LLVM :: CodeGen/X86/vector-compare-combines.ll > LLVM :: CodeGen/X86/vector-narrow-binop.ll > LLVM :: DebugInfo/COFF/vframe-fpo.ll > LLVM :: DebugInfo/X86/debug-info-static-member.ll > LLVM :: FileCheck/check-empty-tag.txt > LLVM :: FileCheck/dump-input-annotations.txt > LLVM :: FileCheck/no-multi-suffixes.txt > LLVM :: FileCheck/var-scope.txt > LLVM :: MC/AsmParser/expr-shr.s > LLVM :: MC/Mips/relocation-n64.s > LLVM :: MC/Mips/relocation.s > LLVM :: MC/RISCV/compressed-relocations.s > LLVM :: MC/RISCV/relocations.s > LLVM :: MC/RISCV/rv32b-aliases-valid.s > LLVM :: MC/RISCV/rv64b-aliases-valid.s > LLVM :: MC/RISCV/rva-aliases-valid.s > LLVM :: MC/RISCV/rvi-aliases-valid.s > LLVM :: Transforms/InstCombine/double-float-shrink-2.ll > LLVM :: Transforms/LoopFusion/cannot_fuse.ll > LLVM :: tools/llvm-objdump/ELF/dynamic-section-machine-specific.test > LLVM :: tools/llvm-readobj/ELF/RISCV/section-types.test > LLVM :: tools/llvm-readobj/ELF/section-types.test > LLVM :: tools/llvm-readobj/ELF/symbol-binding.test > > All of these are variants in some form or another of comments that contain > the check prefix, but which are intentionally not actual CHECK lines. >Thanks for working on this. That report makes me think the diagnostic is going to be frustrating. What do you think? Joel> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200417/873b48b6/attachment.html>
Just to add to this, I have sometimes used a semi-column instead of a column and wondered why it didn't work. Is that included in gotcha A? On Fri, Apr 17, 2020 at 3:04 PM Joel E. Denny via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> As an update, after lots of fixes from a number of different people >> (thanks everyone!), the current list of false-positives on `ninja >> check-llvm` for the more stringent Gotcha A diagnostic is: >> >> LLVM :: Analysis/CostModel/X86/vselect-cost.ll >> LLVM :: CodeGen/AMDGPU/GlobalISel/smrd.ll >> LLVM :: CodeGen/AMDGPU/fp_to_uint.ll >> LLVM :: CodeGen/AMDGPU/global-constant.ll >> LLVM :: CodeGen/AMDGPU/merge-tbuffer.mir >> LLVM :: CodeGen/AMDGPU/smrd.ll >> LLVM :: CodeGen/AMDGPU/unhandled-loop-condition-assertion.ll >> LLVM :: CodeGen/ARM/build-attributes.ll >> LLVM :: CodeGen/ARM/float-helpers.s >> LLVM :: CodeGen/ARM/select-imm.ll >> LLVM :: CodeGen/ARM/struct_byval_arm_t1_t2.ll >> LLVM :: CodeGen/Mips/cconv/arguments-float.ll >> LLVM :: CodeGen/Mips/cconv/arguments-hard-float-varargs.ll >> LLVM :: CodeGen/Mips/cconv/arguments-hard-float.ll >> LLVM :: CodeGen/Mips/cconv/arguments-varargs.ll >> LLVM :: CodeGen/Mips/cconv/arguments.ll >> LLVM :: CodeGen/Mips/cconv/return-hard-fp128.ll >> LLVM :: CodeGen/Mips/cconv/return-hard-struct-f128.ll >> LLVM :: CodeGen/Mips/ci2.ll >> LLVM :: CodeGen/Mips/countleading.ll >> LLVM :: CodeGen/Mips/divrem.ll >> LLVM :: CodeGen/Mips/dynamic-stack-realignment.ll >> LLVM :: CodeGen/Mips/inlineasm-operand-code.ll >> LLVM :: CodeGen/Mips/mips64muldiv.ll >> LLVM :: CodeGen/PowerPC/ppc64-crsave.mir >> LLVM :: CodeGen/X86/avx-cast.ll >> LLVM :: CodeGen/X86/fp-intrinsics.ll >> LLVM :: CodeGen/X86/splat-for-size.ll >> LLVM :: CodeGen/X86/sse-scalar-fp-arith.ll >> LLVM :: CodeGen/X86/vec_shift6.ll >> LLVM :: CodeGen/X86/vector-compare-combines.ll >> LLVM :: CodeGen/X86/vector-narrow-binop.ll >> LLVM :: DebugInfo/COFF/vframe-fpo.ll >> LLVM :: DebugInfo/X86/debug-info-static-member.ll >> LLVM :: FileCheck/check-empty-tag.txt >> LLVM :: FileCheck/dump-input-annotations.txt >> LLVM :: FileCheck/no-multi-suffixes.txt >> LLVM :: FileCheck/var-scope.txt >> LLVM :: MC/AsmParser/expr-shr.s >> LLVM :: MC/Mips/relocation-n64.s >> LLVM :: MC/Mips/relocation.s >> LLVM :: MC/RISCV/compressed-relocations.s >> LLVM :: MC/RISCV/relocations.s >> LLVM :: MC/RISCV/rv32b-aliases-valid.s >> LLVM :: MC/RISCV/rv64b-aliases-valid.s >> LLVM :: MC/RISCV/rva-aliases-valid.s >> LLVM :: MC/RISCV/rvi-aliases-valid.s >> LLVM :: Transforms/InstCombine/double-float-shrink-2.ll >> LLVM :: Transforms/LoopFusion/cannot_fuse.ll >> LLVM :: tools/llvm-objdump/ELF/dynamic-section-machine-specific.test >> LLVM :: tools/llvm-readobj/ELF/RISCV/section-types.test >> LLVM :: tools/llvm-readobj/ELF/section-types.test >> LLVM :: tools/llvm-readobj/ELF/symbol-binding.test >> >> All of these are variants in some form or another of comments that >> contain the check prefix, but which are intentionally not actual CHECK >> lines. >> > > Thanks for working on this. That report makes me think the diagnostic is > going to be frustrating. What do you think? > > Joel > > >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- *Alexandre Isoard* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200418/b0229bb2/attachment.html>
On Fri, Apr 17, 2020 at 4:03 PM Joel E. Denny <jdenny.ornl at gmail.com> wrote:> On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >All of these are variants in some form or another of comments that contain>> the check prefix, but which are intentionally not actual CHECK lines. >> > > Thanks for working on this. That report makes me think the diagnostic is > going to be frustrating. What do you think? >This seems small compared to the number of tests, and even smaller compared to the number of total lines of test. It's also small compared to the number of true positives it has found. These cases can all be easily reworded to avoid the new diagnostic, and we could even add the preferred spelling to avoid it in the diagnostic itself, i.e. "if you want to avoid this, surround with backticks" (or whatever we decide on). IMO, that makes it worthwhile even despite a little discomfort. Jon> > Joel > > >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200418/57b2a827/attachment.html>
Yeah, I've been considering that to be the same kind of bug in these measurements/proposals. On Sat, Apr 18, 2020 at 11:21 AM Alexandre Isoard < alexandre.isoard at gmail.com> wrote:> Just to add to this, I have sometimes used a semi-column instead of a > column and wondered why it didn't work. Is that included in gotcha A? >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200418/d102469e/attachment.html>
On Sat, Apr 18, 2020 at 1:58 PM Jon Roelofs <jroelofs at gmail.com> wrote:> > > On Fri, Apr 17, 2020 at 4:03 PM Joel E. Denny <jdenny.ornl at gmail.com> > wrote: > >> On Mon, Apr 13, 2020 at 1:16 PM Jon Roelofs via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > All of these are variants in some form or another of comments that contain >>> the check prefix, but which are intentionally not actual CHECK lines. >>> >> >> Thanks for working on this. That report makes me think the diagnostic is >> going to be frustrating. What do you think? >> > > This seems small compared to the number of tests, and even smaller > compared to the number of total lines of test. It's also small compared to > the number of true positives it has found. > > These cases can all be easily reworded to avoid the new diagnostic, and we > could even add the preferred spelling to avoid it in the diagnostic > itself, i.e. "if you want to avoid this, surround with backticks" (or > whatever we decide on). > > IMO, that makes it worthwhile even despite a little discomfort. >OK. You've been looking at it more than I have. Which of the heuristic proposals are you testing with now? Any interest in introducing a FileCheck comment syntax? Maybe the regex is '\bRUN:|\bCOM:'? "COM:" would likely be clearer than directive name mangling, either when "fixing" comments for this diagnostic or when just trying to disable a directive for debugging, etc. Joel> > Jon > > >> >> Joel >> >> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200418/810f1dbf/attachment.html>