[llvm-bugs] [Bug 47988] New: Enable build status feedback from Buildkite to GitHub (for release branches)
https://bugs.llvm.org/show_bug.cgi?id=47988 Bug ID: 47988 Summary: Enable build status feedback from Buildkite to GitHub (for release branches) Product: new-bugs Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: kuh...@google.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Problem description --- We have build coverage for the release branches on Buildkite: https://buildkite.com/llvm-project/llvm-releases The build status is not visible on the Github commits. Solution Associate the projects on Github and Buildkite so that Buildkite can report build results back to Github. The person doing this needs to be admin in both projects. For admin access to buildkite contact: kuh...@google.com or goncha...@google.com Instructions for setting this up: https://buildkite.com/docs/integrations/github#to-connect-your-buildkite-account-to-github-using-the-github-app Link to configure the Github integration: https://buildkite.com/organizations/llvm-project/repository-providers/new -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47989] New: Clang-format should use UTF-8 character's width shown in editor rather than storage byte size.
https://bugs.llvm.org/show_bug.cgi?id=47989 Bug ID: 47989 Summary: Clang-format should use UTF-8 character's width shown in editor rather than storage byte size. Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: panzhongx...@126.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org When I input some UTF-8 character rather than simple ASCII, I find that clang-format will take the character's length as how many bytes expressed, rather than as the length show in terminal. For example: `测` is stored in 3 bytes, but it takes 2 ASCII space in vim or other editors. The expected formatted code should be as follow: #define test \ /* 测试 */ \ "aa" \ "bb" \ "bb" But what I really get is as follow: #define test \ /* 测试 */ \ "aa" \ "bb" \ "bb" I have tryed both clang-format 11.0.0 and the newest 12.0.0. I think the width on screen should be used instead of its storage byte size.(Or is there any configuration to control this?) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37872] Instcombine: transform shl(inexact shr(x)) with different constant shifts.
https://bugs.llvm.org/show_bug.cgi?id=37872
Roman Lebedev changed:
What|Removed |Added
Fixed By Commit(s)||0ac56e8eaaeb41b59a952fa4658
||72f647c930347
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Roman Lebedev ---
Done in 0ac56e8eaaeb41b59a952fa465872f647c930347.
This doesn't, however, help D46760: we now end up with:
$ ./bin/opt -O3 /tmp/test.ll -o - -S
; ModuleID = '/tmp/test.ll'
source_filename = "/tmp/test.ll"
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: nounwind
declare i32 @get_number() local_unnamed_addr #0
; Function Attrs: nounwind
define void @narrow_long_chain_with_udiv_urem(i64* nocapture %result)
local_unnamed_addr #0 {
%num1 = tail call i32 @get_number(), !range !0
%num2 = tail call i32 @get_number(), !range !0
%1 = shl nuw nsw i32 %num1, 6
%narrow = add nuw nsw i32 %1, %num2
%2 = and i32 %narrow, 127
%tmp2 = zext i32 %2 to i64
%3 = shl nuw nsw i64 %tmp2, 3
%tmp4 = and i64 %3, 768
%tmp5 = or i64 %tmp4, %tmp2
%tmp6 = or i64 %tmp5, 224
store i64 %tmp6, i64* %result, align 8
ret void
}
attributes #0 = { nounwind }
!0 = !{i32 0, i32 9945}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44504] TestCases/Linux/coverage-missing.cpp failing with python3
https://bugs.llvm.org/show_bug.cgi?id=44504 Alexander Richardson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Alexander Richardson --- Fixed in https://reviews.llvm.org/rG89031cffd1de0ce70106cda1bf5188f7a11726a2 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47972] Trunk - Runtime kernel crash on simple code
https://bugs.llvm.org/show_bug.cgi?id=47972 Jose Manuel Monsalve Diaz changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #6 from Jose Manuel Monsalve Diaz --- The more I explore the more I think this is something on my end. I will close it for now. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47990] New: static assertion in WebAssembly because cannot handle Strict mode
https://bugs.llvm.org/show_bug.cgi?id=47990
Bug ID: 47990
Summary: static assertion in WebAssembly because cannot handle
Strict mode
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: melanie.blo...@intel.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
dmajor added a comment.
After D87528: Enable '#pragma STDC FENV_ACCESS' commit, our bots have a failure
on the wasm target, could you please take a look?
test.c:
double a, b;
c() {
#pragma STDC FENV_ACCESS ON
b == a;
}
Run `clang -cc1 -triple wasm32-unknown-wasi -emit-obj test.c` (clang needs to
be build with `-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly`)
Result:
clang:
/home/vm/src/llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:3764:
bool (anonymous namespace)::SelectionDAGLegalize::ExpandNode(llvm::SDNode *):
Assertion `!IsStrict && "Don't know how to expand for strict nodes."' failed.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47991] New: Assertion in Sparse conditional constant propagation
https://bugs.llvm.org/show_bug.cgi?id=47991 Bug ID: 47991 Summary: Assertion in Sparse conditional constant propagation Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: axel.y.riv...@intel.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 24107 --> https://bugs.llvm.org/attachment.cgi?id=24107&action=edit Simplified test case Hi, I'm getting an assertion with the simple test case that was attached. It can be replicated with the following command: opt -ipsccp -S simple.ll The issue is dying in the following line: %tmp4 = trunc i512 %tmp3 to i32 The truncate function in ConstantRange identifies that it is trying to convert from 8-bits to 32-bits, which triggers the assertion. This is the callback trace: opt: /llvm/llvm/lib/IR/ConstantRange.cpp:721: llvm::ConstantRange llvm::ConstantRange::truncate(uint32_t) const: Assertion `getBitWidth() > DstTySize && "Not a value truncation"' failed. PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: opt -ipsccp -S simple.ll 1. Running pass 'Interprocedural Sparse Conditional Constant Propagation' on module 'simple.ll'. #0 0x036eafe1 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /llvm/llvm/lib/Support/Unix/Signals.inc:563:0 #1 0x036eb098 PrintStackTraceSignalHandler(void*) /llvm/llvm/lib/Support/Unix/Signals.inc:630:0 #2 0x036e90a1 llvm::sys::RunSignalHandlers() /llvm/llvm/lib/Support/Signals.cpp:71:0 #3 0x036eaa24 SignalHandler(int) /llvm/llvm/lib/Support/Unix/Signals.inc:405:0 #4 0x7fe76acd15e0 __restore_rt (/lib64/libpthread.so.0+0xf5e0) #5 0x7fe7698531f7 raise (/lib64/libc.so.6+0x351f7) #6 0x7fe7698548e8 abort (/lib64/libc.so.6+0x368e8) #7 0x7fe76984c266 __assert_fail_base (/lib64/libc.so.6+0x2e266) #8 0x7fe76984c312 (/lib64/libc.so.6+0x2e312) #9 0x02b37e2b llvm::ConstantRange::truncate(unsigned int) const /llvm/llvm/lib/IR/ConstantRange.cpp:722:0 #10 0x02b3766d llvm::ConstantRange::castOp(llvm::Instruction::CastOps, unsigned int) const /llvm/llvm/lib/IR/ConstantRange.cpp:648:0 #11 0x035147ff (anonymous namespace)::SCCPSolver::visitCastInst(llvm::CastInst&) /llvm/llvm/lib/Transforms/Scalar/SCCP.cpp:848:0 #12 0x0351c99d llvm::InstVisitor<(anonymous namespace)::SCCPSolver, void>::visitTruncInst(llvm::TruncInst&) /llvm/llvm/include/llvm/IR/InstVisitor.h:177:0 #13 0x0351c1d1 llvm::InstVisitor<(anonymous namespace)::SCCPSolver, void>::visitTrunc(llvm::TruncInst&) /llvm/llvm/include/llvm/IR/Instruction.def:184:0 #14 0x0351b7db llvm::InstVisitor<(anonymous namespace)::SCCPSolver, void>::visit(llvm::Instruction&) /llvm/llvm/include/llvm/IR/Instruction.def:184:0 #15 0x0351cef4 void llvm::InstVisitor<(anonymous namespace)::SCCPSolver, void>::visit, false, false> >(llvm::ilist_iterator, false, false>, llvm::ilist_iterator, false, false>) /llvm/llvm/include/llvm/IR/InstVisitor.h:89:0 #16 0x0351c676 llvm::InstVisitor<(anonymous namespace)::SCCPSolver, void>::visit(llvm::BasicBlock&) /llvm/llvm/include/llvm/IR/InstVisitor.h:106:0 #17 0x0351baa7 llvm::InstVisitor<(anonymous namespace)::SCCPSolver, void>::visit(llvm::BasicBlock*) /llvm/llvm/include/llvm/IR/InstVisitor.h:111:0 #18 0x03517c5f (anonymous namespace)::SCCPSolver::Solve() /llvm/llvm/lib/Transforms/Scalar/SCCP.cpp:1440:0 #19 0x03519f66 llvm::runIPSCCP(llvm::Module&, llvm::DataLayout const&, std::function, llvm::function_ref) /llvm/llvm/lib/Transforms/Scalar/SCCP.cpp:1969:0 #20 0x02f78133 (anonymous namespace)::IPSCCPLegacyPass::runOnModule(llvm::Module&) /llvm/llvm/lib/Transforms/IPO/SCCP.cpp:68:0 #21 0x02c9456b (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /llvm/llvm/lib/IR/LegacyPassManager.cpp:1634:0 #22 0x02c8fa7d llvm::legacy::PassManagerImpl::run(llvm::Module&) /llvm/llvm/lib/IR/LegacyPassManager.cpp:615:0 #23 0x02c94d57 llvm::legacy::PassManager::run(llvm::Module&) /llvm/llvm/lib/IR/LegacyPassManager.cpp:1762:0 #24 0x01b4c943 main /llvm/llvm/tools/opt/opt.cpp:1001:0 #25 0x7fe76983fc05 __libc_start_mai
[llvm-bugs] [Bug 47746] MergeBlockIntoPredecessor in UnrollLoop is very slow for sufficiently complicated loops
https://bugs.llvm.org/show_bug.cgi?id=47746 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||5a3ef55a524bf9e072d98286e5f ||ebdb218b1fc72 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46358] WinException: off-by-one building IP2state table
https://bugs.llvm.org/show_bug.cgi?id=46358 Reid Kleckner changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- This behavior is working as intended. There is an explanation in this bug, which is arguably a duplicate: https://llvm.org/pr47459 The PCs in the ip2state table form half-open intervals, but a label beginning a new region may appear immediately after a CALL instruction belonging to an earlier region. When an exception is thrown from a CALL instruction, the return address is used to calculate the current EH state, and the return address may be in the next EH state interval. To work around this, LLVM biases all the entries in ip2state forward by one byte. An alternative solution would be to insert nops before EH state transitions, but that costs code size. The nop placement could be more sophisticated, but that has its own complexity costs. I left the other bug open to cover the possibility that we implement the sophisticated nop insertion in the future, but I don't consider it high priority. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47891] Miscompile under PowerPC caused by commit 5415fef3abef
https://bugs.llvm.org/show_bug.cgi?id=47891 Nemanja Ivanovic changed: What|Removed |Added Fixed By Commit(s)||5459d08795e Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #11 from Nemanja Ivanovic --- Fixed in https://reviews.llvm.org/rG5459d08795e Please confirm with the original code. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26688 in oss-fuzz: llvm:clang-objc-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-10-27 Type: Bug New issue 26688 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26688 Detailed Report: https://oss-fuzz.com/testcase?key=5668259288055808 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal clang::ObjCMethodDecl::findPropertyDecl clang::Sema::DiagnoseUseOfDecl Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201912130427:201912200437 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5668259288055808 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 22260 in oss-fuzz: llvm: Coverage build failure
Comment #22 on issue 22260 by ClusterFuzz-External: llvm: Coverage build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=22260#c22 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-d65a72f6-e72e-4a5c-95a5-da08790c510a.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 26695 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in LookupDirect
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-10-28 Type: Bug New issue 26695 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in LookupDirect https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26695 Detailed Report: https://oss-fuzz.com/testcase?key=5680645302648832 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffcf52aeff8 Crash State: LookupDirect clang::Sema::LookupQualifiedName clang::Sema::DiagnoseEmptyLookup Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202009040608:202009050603 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5680645302648832 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
