[llvm-bugs] [Bug 44496] New: [SystemZ] Bad machine code: Expected a register operand
https://bugs.llvm.org/show_bug.cgi?id=44496 Bug ID: 44496 Summary: [SystemZ] Bad machine code: Expected a register operand Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: SystemZ Assignee: unassignedb...@nondot.org Reporter: pauls...@linux.vnet.ibm.com CC: llvm-bugs@lists.llvm.org Created attachment 23001 --> https://bugs.llvm.org/attachment.cgi?id=23001&action=edit reduced testcase llc -O3 -mcpu=z15 ./tc_exptectedreg_nxgrk.ll -verify-misched -o - *** Bad machine code: Expected a register operand. *** - function:main - basic block: %bb.1 bb1 (0x2aa410c5488) [80B;336B) - instruction: 176B %6:gr64bit = NXGRK %1:gr64bit, -4210509929515057152, implicit-def dead $cc - operand 2: -4210509929515057152 LLVM ERROR: Found 1 machine code errors. -- 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 44495] New: Assertion failed: Enum value too large in dumpSectionMap
https://bugs.llvm.org/show_bug.cgi?id=44495 Bug ID: 44495 Summary: Assertion failed: Enum value too large in dumpSectionMap Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: tras...@gmail.com CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com Created attachment 23000 --> https://bugs.llvm.org/attachment.cgi?id=23000&action=edit test pdb llvm-pdbutil.exe dump --all test.pdb Section Map Section | ovl = 0, group = 0, frame = 0, name = 0 class = 0, offset = 0, size = 263190608 flags = none Section 0001 | ovl = 0, group = 0, frame = 0, name = 0 class = 0, offset = 2806971904, size = 1324946622 flags = read | write | execute | absolute addr Section 0002 | ovl = 33812, group = 18389, frame = 1331, name = 32192 class = 21609, offset = 32765, size = 268430928 Assertion failed: U <= Mask() && "Enum value too large (or largest val too small?)", file include\llvm/ADT/BitmaskEnum.h, line 93 llvm::pdb::DumpOutputStyle::dumpSectionMap() llvm::pdb::DumpOutputStyle::dump() -- 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 19959 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-01-09 Type: Bug New issue 19959 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-gisel: ASSERT: N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19959 Detailed Report: https://oss-fuzz.com/testcase?key=5724538583384064 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-gisel Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: N->getOpcode() != ISD::DELETED_NODE && "DELETED_NODE in CSEMap!" llvm::SelectionDAG::RemoveNodeFromCSEMaps llvm::SelectionDAG::ReplaceAllUsesOfValuesWith Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801020611:201801030610 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5724538583384064 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] [Bug 44494] New: Crash when using unique_ptr with deleter
https://bugs.llvm.org/show_bug.cgi?id=44494
Bug ID: 44494
Summary: Crash when using unique_ptr with deleter
Product: clang
Version: 9.0
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: qiu...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Compiling the following code with c++17 crashes. clang 9.0.1(with an irrelevant
local commit)
#include
std::unique_ptr NewAligned(const size_t size) {
void* ptr = nullptr;
if (posix_memalign(&ptr, 4 * 1024, size) != 0) {
return std::unique_ptr(nullptr, free);
}
std::unique_ptr uptr(ptr, free);
return uptr;
}
size_t g();
void use_pointer(void *p);
void use(){
auto x = NewAligned(g());
use_pointer(x.get());
}
This method is used in some version of rocksdb, io_posix.cc
clang-9: /home/c/llvm-project/clang/lib/CodeGen/CodeGenFunction.h:4270: void
clang::CodeGen::CodeGenFunction::EmitCallArgs(clang::CodeGen::CallArgList&,
const T*, llvm::iterator_range >,
clang::CodeGen::CodeGenFunction::AbstractCallee, unsigned int,
clang::CodeGen::CodeGenFunction::EvaluationOrder) [with T =
clang::FunctionProtoType]: Assertion `(isGenericMethod ||
((*I)->isVariablyModifiedType() ||
(*I).getNonReferenceType()->isObjCRetainableType() || getContext()
.getCanonicalType((*I).getNonReferenceType()) .getTypePtr() == getContext()
.getCanonicalType((*Arg)->getType()) .getTypePtr())) && "type mismatch in call
argument!"' failed.
Stack dump:
0. Program arguments: /home/c/clang/bin/clang-9 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
uniq_ptr.cc -mrelocation-model static -mthread-model posix -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables
-fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb
-coverage-notes-file /home/c/play/uniq_ptr.gcno -resource-dir
/home/c/clang/lib/clang/9.0.1 -internal-isystem
/home/c/play/../clang/bin/../lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0
-internal-isystem
/home/c/play/../clang/bin/../lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/x86_64-linux-gnu/c++/7.4.0
-internal-isystem
/home/c/play/../clang/bin/../lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/x86_64-linux-gnu/c++/7.4.0
-internal-isystem
/home/c/play/../clang/bin/../lib/gcc/x86_64-linux-gnu/7.4.0/../../../../include/c++/7.4.0/backward
-internal-isystem /usr/local/include -internal-isystem
/home/c/clang/lib/clang/9.0.1/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include --std=c++17 -fdeprecated-macro
-fdebug-compilation-dir /home/c/play -ferror-limit 19 -fmessage-length 0
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -faddrsig -o uniq_ptr.o -x c++ uniq_ptr.cc
1. uniq_ptr.cc:12:1: current parser token 'size_t'
2. uniq_ptr.cc:3:40: LLVM IR generation of declaration 'NewAligned'
3. uniq_ptr.cc:3:40: Generating code for declaration 'NewAligned'
4. uniq_ptr.cc:5:50: LLVM IR generation of compound statement ('{}')
/home/c/clang/bin/clang-9(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2a)[0x27a548a]
/home/c/clang/bin/clang-9(_ZN4llvm3sys17RunSignalHandlersEv+0x4c)[0x27a2fbc]
/home/c/clang/bin/clang-9[0x27a3129]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f56660c5390]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f5664e37428]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f5664e3902a]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dbd7)[0x7f5664e2fbd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f5664e2fc82]
/home/c/clang/bin/clang-9[0x2ac5b32]
/home/c/clang/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction22EmitCXXConstructorCallEPKNS_18CXXConstructorDeclENS_11CXXCtorTypeEbbNS0_12AggValueSlotEPKNS_16CXXConstructExprE+0x25f)[0x2b9df8f]
/home/c/clang/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction20EmitCXXConstructExprEPKNS_16CXXConstructExprENS0_12AggValueSlotE+0x35f)[0x2c0387f]
/home/c/clang/bin/clang-9[0x9e59f7]
/home/c/clang/bin/clang-9[0x2bf83b0]
/home/c/clang/bin/clang-9[0x2bf9717]
/home/c/clang/bin/clang-9[0x2bf8aad]
/home/c/clang/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction11EmitAggExprEPKNS_4ExprENS0_12AggValueSlotE+0xde)[0x2bf981e]
/home/c/clang/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction14EmitReturnStmtERKNS_10ReturnStmtE+0x525)[0x29f66e5]
/home/c/clang/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction8EmitStmtEPKNS_4StmtEN4llvm8ArrayRefIPKNS_4AttrEEE+0x5a2)[0x29f8742]
/home/c/clang/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunction28EmitCompoundStmtWithoutScopeERKNS_12CompoundStmtEbNS0_12AggValueSlotE+0x254)[0x29f9564]
/home/c/clang/bin/clang-9(_ZN5clang7CodeGen15CodeGenFunctio
[llvm-bugs] [Bug 44462] X86FlagsCopyLowering.cpp fails to remove killed $eflags from successor live-ins
https://bugs.llvm.org/show_bug.cgi?id=44462 Jonas Paulsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonas Paulsson --- ee57469 -- 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 44493] New: Assertion failure when expanding variadic macros for plist output
https://bugs.llvm.org/show_bug.cgi?id=44493
Bug ID: 44493
Summary: Assertion failure when expanding variadic macros for
plist output
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: xazax@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
I get the following assertion failure:
clang-10:
/usr/local/google/home/xazax/LLVM/clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp:1171:
(anonymous namespace)::MacroNameAndArgs
getMacroNameAndArgs(clang::SourceLocation, const clang::Preprocessor &):
Assertion `TheTok.is(tok::r_paren) && "Expanded macro argument acquisition
failed! After the end of the loop" " this token should be ')'!"' failed.
I vaguely recall variadic macros not being supported yet, but I think we should
not have an assert failure.
Minimal repro:
#define log(args...) \
do { \
} while (0)
int main(int argc, char** argv) {
log("arg");
log("arg", "arg2");
int a;
a & 0xffc0;
return 0;
}
Command line:
clang-10 --analyze --analyzer-output plist-multi-file -o out.plist -Xclang
-analyzer-config -Xclang expand-macros=true minimal.cpp
--
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 35389] Support ppc64le
https://bugs.llvm.org/show_bug.cgi?id=35389 sfert...@ca.ibm.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from sfert...@ca.ibm.com --- Closing this: Full powerpc64 support was finished some time ago. -- 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 19951 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: ASSERT: hasVal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-01-08 Type: Bug New issue 19951 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: ASSERT: hasVal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19951 Detailed Report: https://oss-fuzz.com/testcase?key=5652192812072960 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: hasVal llvm::DWARFDie::getAddressRanges llvm::DWARFDie::dump Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201902180416:201902190429 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5652192812072960 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] [Bug 43750] [AVX512] cannot select: extract f64 from splatted "movemask"
https://bugs.llvm.org/show_bug.cgi?id=43750 Craig Topper changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||d60b3b4817cb9346b682bb75371 ||c41642c273b13 --- Comment #3 from Craig Topper --- Fixed by d60b3b4817cb9346b682bb75371c41642c273b13 -- 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 44485] clang-analyzer-security.insecureAPI.rand false positive for C++ class method
https://bugs.llvm.org/show_bug.cgi?id=44485 Eugene Zelenko changed: What|Removed |Added Assignee|unassignedclangbugs@nondot. |dcough...@apple.com |org | CC||dcough...@apple.com, ||eugene.zele...@gmail.com, ||llvm-bugs@lists.llvm.org Component|clang-tidy |Static Analyzer Product|clang-tools-extra |clang -- 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 44492] New: CallAndMessage false positive for "T* const member" while it's not nullptr
https://bugs.llvm.org/show_bug.cgi?id=44492
Bug ID: 44492
Summary: CallAndMessage false positive for "T* const member"
while it's not nullptr
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: zinovy@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
The following code emits false-positive
#include
#include
class C {
public:
int foo(int x) { return x * 2; }
};
class A {
public:
A(C* c, std::string s) : c_(c), s_(s) {
assert(c_);
bar("12345");
c_->foo(42);
}
void bar(std::string s) {
// s_, not c_!
// c_ is not changed here.
s_ = s;
}
private:
std::string s_;// [1]
C* const c_ = nullptr; // [2]
};
int main(int argc, char** /*unused*/) {
C* c = new C;
A a(c, "123");
return 1;
};
> clang-tidy.exe -checks=-*,*CallAndMessage* test.cc
...
test.cc:14:5: warning: Called C++ object pointer is null
[clang-analyzer-core.CallAndMessage]
c_->foo(42);
^
test.cc:29:5: note: Calling constructor for 'A'
A a(c, "123");
^
test.cc:12:12: note: Field 'c_' is non-null
assert(c_);
^
test.cc:12:12: note: Field 'c_' is non-null
test.cc:12:5: note: Left side of '||' is true
assert(c_);
^
C:\Program Files (x86)\Windows
Kits\10\Include\10.0.18362.0\ucrt\assert.h:33:30: note: expanded from macro
'assert'
(!!(expression)) ||
\
^
test.cc:13:5: note: Calling 'A::bar'
bar("12345");
^
test.cc:19:5: note: Null pointer value stored to 'a.c_'
s_ = s;
^
test.cc:13:5: note: Returning from 'A::bar'
bar("12345");
^
test.cc:14:5: note: Called C++ object pointer is null
c_->foo(42);
^
"c_" is considered nullptr, while it's not changed during a call to "bar".
Moreover, 1) if we swap [1] and [2] lines, then CallAndMessage is not raised;
2) if we remove 'const' in [2] then CallAndMessage is not raised.
--
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 18311 in oss-fuzz: llvm:clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes
Updates: Labels: Deadline-Approaching Comment #2 on issue 18311 by sheriff...@chromium.org: llvm:clang-fuzzer: ASSERT: cast(SubExpr)->getQualifier() && "fixed to a member ref with no nes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18311#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 18312 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: Index < Length && "Invalid index!"
Updates: Labels: Deadline-Approaching Comment #2 on issue 18312 by sheriff...@chromium.org: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: Index < Length && "Invalid index!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18312#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 18306 in oss-fuzz: llvm:llvm-isel-fuzzer--wasm32-O2: ASSERT: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?"
Updates: Labels: Deadline-Approaching Comment #2 on issue 18306 by sheriff...@chromium.org: llvm:llvm-isel-fuzzer--wasm32-O2: ASSERT: (Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18306#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 18295 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal
Updates: Labels: Deadline-Approaching Comment #2 on issue 18295 by sheriff...@chromium.org: llvm:clang-fuzzer: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18295#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 19713 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 19713 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::StmtVisitorBaseIntExprEvaluator, bool>::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19713#c1 ClusterFuzz testcase 5743930503331840 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202001060422:202001080427 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- 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] [Bug 44491] New: lld-link does not understand /PDBSTRIPPED
https://bugs.llvm.org/show_bug.cgi?id=44491 Bug ID: 44491 Summary: lld-link does not understand /PDBSTRIPPED Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Keywords: compile-fail Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: tras...@gmail.com CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org lld-link : error : could not open '/PDBSTRIPPED:testp.pdb': invalid argument It seems to treat it as an input file. -- 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 44489] New: Assertion failed in YAMLStringTableSubsection::fromCodeViewSubsection
https://bugs.llvm.org/show_bug.cgi?id=44489 Bug ID: 44489 Summary: Assertion failed in YAMLStringTableSubsection::fromCodeViewSubsection Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Keywords: compile-fail Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: tras...@gmail.com CC: jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, paul_robin...@playstation.sony.com Created attachment 22999 --> https://bugs.llvm.org/attachment.cgi?id=22999&action=edit test pdb $ llvm-pdbutil.exe pdb2yaml --all test.pdb Assertion failed: S.empty(), file llvm\lib\ObjectYAML\CodeViewYAMLDebugSections.cpp, line 698 S is not empty, but ".\\mingw-w64-crt\\crt\\crtexe.c" Pretty dump: Attributes: HasPrivateSymbols ---COMPILANDS--- __Globals .\mingw-w64-crt\crt\crtexe.c Line 130, Address: [0x1000] (0 bytes) Line 135, Address: [0x1000 - 0x100f] (16 bytes) [...] -- 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 44488] New: Miscompile with opt -loop-vectorize
https://bugs.llvm.org/show_bug.cgi?id=44488
Bug ID: 44488
Summary: Miscompile with opt -loop-vectorize
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: mikael.hol...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Created attachment 22998
--> https://bugs.llvm.org/attachment.cgi?id=22998&action=edit
bbi-37172.ll reproducer
I think I've found a case where -loop-vectorize produces wrong code.
Reproduce with
opt -loop-vectorize -S -o - bbi-37172.ll
The input looks like
--
@v_38 = global i16 12061, align 1
@v_39 = global i16 11333, align 1
define i16 @main() {
entry:
br label %for.body
for.cond.cleanup: ; preds = %cond.end5
%0 = load i16, i16* @v_39, align 1
ret i16 %0
for.body: ; preds = %entry, %cond.end5
%i.07 = phi i16 [ 99, %entry ], [ %inc7, %cond.end5 ]
%1 = load i16, i16* @v_38, align 1
%cmp1 = icmp eq i16 %1, 32767
br i1 %cmp1, label %cond.end, label %cond.end
cond.end: ; preds = %for.body,
%for.body
%cmp2 = icmp eq i16 %1, 0
br i1 %cmp2, label %cond.end5, label %cond.false4
cond.false4: ; preds = %cond.end
%rem = srem i16 5786, %1
br label %cond.end5
cond.end5:; preds = %cond.end,
%cond.false4
%cond6 = phi i16 [ %rem, %cond.false4 ], [ 5786, %cond.end ]
store i16 %cond6, i16* @v_39, align 1
%inc7 = add nsw i16 %i.07, 1
%cmp = icmp slt i16 %inc7, 111
br i1 %cmp, label %for.body, label %for.cond.cleanup, !llvm.loop !26
}
--
If we just focus at the beginning of the loop we have
--
for.body: ; preds = %entry, %cond.end5
%i.07 = phi i16 [ 99, %entry ], [ %inc7, %cond.end5 ]
%1 = load i16, i16* @v_38, align 1
%cmp1 = icmp eq i16 %1, 32767
br i1 %cmp1, label %cond.end, label %cond.end
cond.end: ; preds = %for.body,
%for.body
%cmp2 = icmp eq i16 %1, 0
br i1 %cmp2, label %cond.end5, label %cond.false4
cond.false4: ; preds = %cond.end
%rem = srem i16 5786, %1
br label %cond.end5
--
v_38 is 12061 and we will always branch from for.body to cond.end.
Then we do
%cmp2 = icmp eq i16 %1, 0
which will be false, so
br i1 %cmp2, label %cond.end5, label %cond.false4
will branch to cond.false4 where we will execute the srem
%rem = srem i16 5786, %1
v_38 doesn't change throughout the program so this is the path we will use
every loop round.
After vectorization, we instead get the following:
--
vector.body: ; preds =
%pred.srem.continue2, %vector.ph
%index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.srem.continue2 ]
%0 = trunc i32 %index to i16
%offset.idx = add i16 99, %0
%broadcast.splatinsert = insertelement <2 x i16> undef, i16 %offset.idx, i32
0
%broadcast.splat = shufflevector <2 x i16> %broadcast.splatinsert, <2 x i16>
undef, <2 x i32> zeroinitializer
%induction = add <2 x i16> %broadcast.splat,
%1 = add i16 %offset.idx, 0
%2 = load i16, i16* @v_38, align 1
%3 = load i16, i16* @v_38, align 1
%4 = insertelement <2 x i16> undef, i16 %2, i32 0
%5 = insertelement <2 x i16> %4, i16 %3, i32 1
%6 = icmp eq <2 x i16> %5,
%7 = icmp eq <2 x i16> %5, zeroinitializer
%8 = or <2 x i1> %6, %6
%9 = xor <2 x i1> %7,
%10 = and <2 x i1> %9, %8
%11 = extractelement <2 x i1> %10, i32 0
br i1 %11, label %pred.srem.if, label %pred.srem.continue
pred.srem.if: ; preds = %vector.body
%12 = srem i16 5786, %2
%13 = insertelement <2 x i16> undef, i16 %12, i32 0
br label %pred.srem.continue
--
Since v_38 is 12061, %5 will be <12061, 12061>, and thus both %6 and %7 will
be <0, 0>.
>From this we get that %8 is <0, 0>, %9 is <1, 1> and finally %10 is then <0,
0>.
%11 will be 0, and we will thus branch to pred.srem.continue and not execute
the srem.
In pred.srem.continue we then have
--
pred.srem.continue: ; preds = %pred.srem.if,
%vector.body
%14 = phi <2 x i16> [ undef, %vector.body ], [ %13, %pred.srem.if ]
%15 = extractelement <2 x i1> %10, i32 1
br i1 %15, label %pred.srem.if1, label %pred.srem.continue2
pred.srem.if1:; preds = %pred.srem.continue
%16 = srem i16 5786, %3
%17 = insertelement <2 x i16> %14, i16 %16, i32 1
br label %pred.srem.continue2
--
%10 is still <0, 0> so also %15 will be 0, and we will branch to
pred.srem.continue2 a
[llvm-bugs] [Bug 44272] [CLANG-CL] 64x inline assembler function call/jump miscompiled
https://bugs.llvm.org/show_bug.cgi?id=44272 Martynas Skirmantas changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Martynas Skirmantas --- Hello, I've reopened the bug report once more because the bug has not been fully fixed! The "jmp" instruction and other jump instructions such as "ccjmp" still have the same fatal issue, I've also noticed that the compiler is still atempting to dereference the function pointer on the "lea" instruction as well with the RIP (RIP + PTR), has anyone even tested if the problem has been fully fixed? This is very unprofessional. Its even stated in the bug report title that its not just the "call" instruction, jump instructions are of high importance as well. Thank you. -- 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 44487] New: Commenting out case lines in switch statement. Last case behaves differently.
https://bugs.llvm.org/show_bug.cgi?id=44487
Bug ID: 44487
Summary: Commenting out case lines in switch statement. Last
case behaves differently.
Product: clang
Version: 8.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: jzpigtc4...@0box.eu
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
In the midst of a switch statement, clang-format recognizes if a case line is
commented out. But at the end, at the last case, does *not*. At least in
version 8. At least I did not succeed to make such configuration file
(.clang-format) which eliminates this inconsistent behaviour.
$ clang-format -version
clang-format version 8.0.0-3 (tags/RELEASE_800/final)
$ cat gg.c
switch (a) {
case A: blah(1); break;
case B: blah(2); break;
// case C: blah(3); break;
case D: blah(4); break;
}
$ cat g1.c
switch (a) {
case A: blah(1); break;
case B: blah(2); break;
case C: blah(3); break;
// case D: blah(4); break;
}
$ clang-format -style=file gg.c
switch (a) {
case A: blah(1); break;
case B: blah(2); break;
// case C: blah(3); break;
case D: blah(4); break;
}
$ clang-format -style=file g1.c
switch (a) {
case A: blah(1); break;
case B: blah(2); break;
case C:
blah(3);
break;
// case D: blah(4); break;
}
--
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 44443] Fix printing of malformed address values not passed via stdin
https://bugs.llvm.org/show_bug.cgi?id=3 Xuanda Yang changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Xuanda Yang --- Fixed at https://reviews.llvm.org/D72313 -- 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 44486] New: clang-format breaks doxygen content
https://bugs.llvm.org/show_bug.cgi?id=44486 Bug ID: 44486 Summary: clang-format breaks doxygen content Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: marc.a...@oracle.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Consider the following doxygen comment: /** Some doxygen text. Part 1, ok to re format. @verbatim Part 2, should be left as is. @endverbatim Part 3, ok to reformat. Part 4 is UML below, should be left as is. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml Part 5, ok to re format. */ When part 2 and 4 have long lines, which is very frequent, clang-format breaks the content when reformatting the text. Even worse, the c++ code builds, and the doc may even build, producing garbage, so the break might go unnoticed. I am aware of clang-format off/on, but this is not a good solution: - using clang-format off/on for the entire comment disables too much. - interleaving clang-format off/on inside doxygen blocks is too cumbersome, and might not even be possible in all cases. I am aware of bug#19633, and I agree clang-format can not do much about it, since there is no markers in the use case for this bug. Here however, the situation is different: there are existing markers in the source, so it would help to have clang-format honor them. This feature request is to provide a way to tell clang-format about alternate strings to use instead 'clang-format off' / 'clang-format on' markers. For example, with this entry in .clang-format: # Proposal: Alternate markers for 'clang-format off' ... 'clang-format on' Formatting: - Off: '@verbatim' On: '@endverbatim' - Off: '@startuml' On: '@enduml' - Off: 'my-own-tool-begin-marker' On: 'my-own-tool-end-marker' clang-format would turn off formatting when finding the '@verbatim' marker, and enable formatting when finding '@endverbatim', and likewise for UML. Allowing end users to provide their own arbitrary markers helps to support any tool, not only doxygen. Regards, -- Marc Alff -- 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
