[llvm-bugs] [Bug 37053] [llvm-exegesis] Add an option to disable libpfm even if installed.
https://bugs.llvm.org/show_bug.cgi?id=37053 cour...@google.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from cour...@google.com --- Fixed by https://reviews.llvm.org/D45436 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37309] New: Missed optimizations when ANDing comparisons
https://bugs.llvm.org/show_bug.cgi?id=37309 Bug ID: 37309 Summary: Missed optimizations when ANDing comparisons Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: david.bolvan...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, Code: int foo(long a, long b, long c) { int h1 = a > b; int h2 = a > c; return h1 & h2; } Clang with -O3 generates: foo: cmp rdi, rsi setg al cmp rdi, rdx setg cl and cl, al movzx eax, cl ret But maybe a better code can be generated? Like: foo: cmp rsi, rdx cmovl rsi, rdx xor eax, eax cmp rdi, rsi setg al ret -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37310] New: [TableGen] Add more checks to the subtarget emitter to validate scheduling information.
https://bugs.llvm.org/show_bug.cgi?id=37310 Bug ID: 37310 Summary: [TableGen] Add more checks to the subtarget emitter to validate scheduling information. Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: cour...@google.com CC: llvm-bugs@lists.llvm.org Some scheduling information makes no sense but makes it through the SubtargetEmitter without any warnings. We should add more validation. Stuff that makes absolutely no sense should trigger fatal errors. One example I stumbled upon is inconsistencies in resource units vs resource cycles: The cycles are optional and default to all ones, opening up to various miserpretations by the developers that are not caught at compile time. This happens at least on Arm/AArch64 and X86. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37311] New: Can't get register for value! UNREACHABLE executed at ../lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:1344!
https://bugs.llvm.org/show_bug.cgi?id=37311 Bug ID: 37311 Summary: Can't get register for value! UNREACHABLE executed at ../lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:13 44! Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: franci...@yahoo.com CC: llvm-bugs@lists.llvm.org Created attachment 20253 --> https://bugs.llvm.org/attachment.cgi?id=20253&action=edit C++ source. Code from http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180430/547569.html. $ clang -v clang version 7.0.0 (https://llvm.org/git/clang b7af214275695a5cdf1aa0d2305023560917cd03) (llvm/trunk 331259) $ clang cfi.cc -fsanitize=cfi -fwhole-program-vtables -flto -fvisibility=hidden -g -O2 -fno-omit-frame-pointer -target x86_64-linux-unknown -c -S -o cfi.ll $ llc cfi.ll Can't get register for value! UNREACHABLE executed at ../lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:1344! Stack dump: 0. Program arguments: /Users/francisvm/llvm/llvm/build/bin/llc cfi.ll 1. Running pass 'Function Pass Manager' on module 'cfi.ll'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z1cv' 0 llc 0x0001082e494c llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60 1 llc 0x0001082e4ee9 PrintStackTraceSignalHandler(void*) + 25 2 llc 0x0001082e0ad9 llvm::sys::RunSignalHandlers() + 425 3 llc 0x0001082e52a2 SignalHandler(int) + 354 4 libsystem_platform.dylib 0x7fff69ea4d9a _sigtramp + 26 5 libsystem_platform.dylib 0x00011ccb3135 _sigtramp + 3001082805 6 libsystem_c.dylib0x7fff69d60f79 abort + 127 7 llc 0x000108199c00 llvm::install_out_of_memory_new_handler() + 0 8 llc 0x000107f8e0af llvm::SelectionDAGBuilder::getValueImpl(llvm::Value const*) + 6751 9 llc 0x000107f8c5aa llvm::SelectionDAGBuilder::getValue(llvm::Value const*) + 170 10 llc 0x000107fa819a llvm::SelectionDAGBuilder::visitTargetIntrinsic(llvm::CallInst const&, unsigned int) + 826 11 llc 0x000107fa9d54 llvm::SelectionDAGBuilder::visitIntrinsicCall(llvm::CallInst const&, unsigned int) + 3236 12 llc 0x000107f8361f llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 367 13 llc 0x000107f76fb7 llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 1223 14 llc 0x000107f75f58 llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 152 15 llc 0x00010809320e llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>, llvm::ilist_iterator, false, true>, bool&) + 206 16 llc 0x000108091c11 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 10513 17 llc 0x00010808d6c2 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 2674 18 llc 0x00010641081b (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 59 19 llc 0x000107022031 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 449 20 llc 0x00010767fcef llvm::FPPassManager::runOnFunction(llvm::Function&) + 399 21 llc 0x0001076801f5 llvm::FPPassManager::runOnModule(llvm::Module&) + 117 22 llc 0x000107680fcc (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) + 2204 23 llc 0x0001076804b6 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 342 24 llc 0x000107681d11 llvm::legacy::PassManager::run(llvm::Module&) + 33 25 llc 0x000104cf4351 compileModule(char**, llvm::LLVMContext&) + 20385 26 llc 0x000104cee653 main + 5123 27 libdyld.dylib0x7fff69ca5f45 start + 1 28 libdyld.dylib0x0002 start + 2520096958 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37153] X86AvoidStoreForwardingBlocks breaks -verify-machineinstrs
https://bugs.llvm.org/show_bug.cgi?id=37153 Francis Visoiu Mistrih changed: What|Removed |Added Resolution|--- |FIXED CC||franci...@yahoo.com Status|NEW |RESOLVED Fixed By Commit(s)||330939 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34477] Incorrect debug values for variables due to phi-related DBG_VALUEs moved in ISel
https://bugs.llvm.org/show_bug.cgi?id=34477 bjorn.a.petters...@ericsson.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from bjorn.a.petters...@ericsson.com --- This problem is solved by the series of commits that resolves https://bugs.llvm.org/show_bug.cgi?id=37234 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37234] Recent regression in -O2 -g debugging quality since change to improve handling of dangling debug info
https://bugs.llvm.org/show_bug.cgi?id=37234 bjorn.a.petters...@ericsson.com changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from bjorn.a.petters...@ericsson.com --- I made a follow-up commit to rL331182, as I noticed that I forgot to handle PHI nodes that are split into several PHI-nodes when lowering the IR to machine instructions. So the full set of patches that resolves this bug report is: https://llvm.org/svn/llvm-project/llvm/trunk@331182 https://llvm.org/svn/llvm-project/llvm/trunk@331183 https://llvm.org/svn/llvm-project/llvm/trunk@331337 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37312] New: Assertion failure in create_call_once_funcptr_call()
https://bugs.llvm.org/show_bug.cgi?id=37312 Bug ID: 37312 Summary: Assertion failure in create_call_once_funcptr_call() Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Static Analyzer Assignee: ekarpen...@apple.com Reporter: ale...@google.com CC: dcough...@apple.com, ga...@apple.com, llvm-bugs@lists.llvm.org, noqnoq...@gmail.com $ cat test-CFGBuilder__appendCall.cc namespace std { struct a { int _M_once; }; template void call_once(b &&, c &&...); } // namespace std class d { typedef void (*e)(int *, d *); int f; void g() { call_once(h, i, &f, this); } e i; std::a h; }; $ ./clang-tidy -checks=-*,clang-analyzer* test-CFGBuilder__appendCall.cc -- -std=c++11 -fsized-deallocation -Wno-everything assert.h assertion failed at llvm/tools/clang/lib/AST/Expr.cpp:1570 in bool clang::CastExpr::CastConsistency() const: getSubExpr()->getType()->isFunctionType() @ 0x5627c34d9c56 __assert_fail @ 0x5627c22b2036 clang::CastExpr::CastConsistency() @ 0x5627c1961767 clang::CastExpr::CastExpr() @ 0x5627c22b25f4 clang::ImplicitCastExpr::Create() @ 0x5627c1e8f8dd create_call_once_funcptr_call() @ 0x5627c1e8e2b2 create_call_once() @ 0x5627c1e8d274 clang::BodyFarm::getBody() @ 0x5627c1e83fa4 clang::AnalysisDeclContext::getBody() @ 0x5627c1273a48 clang::ento::AnyFunctionCall::getRuntimeDefinition() @ 0x5627c12cd3b6 clang::ento::ExprEngine::defaultEvalCall() @ 0x5627c1288429 clang::ento::CheckerManager::runCheckersForEvalCall() @ 0x5627c12cbf33 clang::ento::ExprEngine::evalCall() @ 0x5627c12cbcc2 clang::ento::ExprEngine::VisitCallExpr() @ 0x5627c1299633 clang::ento::ExprEngine::Visit() @ 0x5627c12953ae clang::ento::ExprEngine::ProcessStmt() @ 0x5627c12950cb clang::ento::ExprEngine::processCFGElement() @ 0x5627c12b99c5 clang::ento::CoreEngine::HandlePostStmt() @ 0x5627c12b8e1d clang::ento::CoreEngine::ExecuteWorkList() @ 0x5627c0fed7ac (anonymous namespace)::AnalysisConsumer::ActionExprEngine() @ 0x5627c0fed326 (anonymous namespace)::AnalysisConsumer::HandleCode() @ 0x5627c0fd9094 (anonymous namespace)::AnalysisConsumer::HandleTranslationUnit() -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37278] Devirtualization optimization missed
https://bugs.llvm.org/show_bug.cgi?id=37278 Marco Satti changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6101 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal
Updates: Labels: Deadline-Approaching Comment #2 on issue 6101 by sheriff...@chromium.org: llvm/llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6101#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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 6109 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-sccp: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"
Updates: Labels: Deadline-Approaching Comment #2 on issue 6109 by sheriff...@chromium.org: llvm/llvm-opt-fuzzer--x86_64-sccp: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6109#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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37313] New: Missed optimizations for comparison of doubles in loops
https://bugs.llvm.org/show_bug.cgi?id=37313 Bug ID: 37313 Summary: Missed optimizations for comparison of doubles in loops Product: libraries Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: david.bolvan...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, double test(double *arr, int size) { double m = INFINITY; int flag = 1; int i; double a; for (i=0; ihttps://godbolt.org/g/iSjSGW Seems like Clang generates worse code because LLVM missed same patterns.. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37309] Missed optimizations when ANDing "great than" comparisons
https://bugs.llvm.org/show_bug.cgi?id=37309 David Bolvansky changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Bolvansky --- Measured and you are right, cmov version slowed down this significatly. I will close 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37309] Missed optimizations when ANDing "great than" comparisons
https://bugs.llvm.org/show_bug.cgi?id=37309 David Bolvansky changed: What|Removed |Added Resolution|FIXED |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37314] New: Make init list narrowing diags not DefaultIgnored in clang-cl mode
https://bugs.llvm.org/show_bug.cgi?id=37314 Bug ID: 37314 Summary: Make init list narrowing diags not DefaultIgnored in clang-cl mode Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++11 Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: dgre...@apple.com, llvm-bugs@lists.llvm.org warn_init_list_type_narrowing, warn_init_list_variable_narrowing, warn_init_list_constant_narrowing are currently DefaultIgnore. The only 3 places that reference these DefaultIgnore versions are here and the next few lines: http://llvm-cs.pcc.me.uk/tools/clang/lib/Sema/SemaInit.cpp#8366 All 3 cases look like so: case NK_Type_Narrowing: // This was a floating-to-integer conversion, which is always considered a // narrowing conversion even if the value is a constant and can be // represented exactly as an integer. S.Diag(PostInit->getLocStart(), (S.getLangOpts().MicrosoftExt || !S.getLangOpts().CPlusPlus11) ? diag::warn_init_list_type_narrowing : diag::ext_init_list_type_narrowing) << PostInit->getSourceRange() << PreNarrowingType.getLocalUnqualifiedType() << EntityType.getLocalUnqualifiedType(); break; So they're only DefaultIgnored in clang-cl mode, not in clang mode. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20120116/051498.html added 2 of these 3 blocks, probably modeled after the 1 that was there. And that one is from https://reviews.llvm.org/rL137904 from 6 years ago by fpichet, before we had come up with a principled way of handling cl.exe compatibility. We should probably try to emit these in MS mode as well (in headers, they'll be ignored and things should hopefully work), or if that causes issues, at least do so if the -fmsc-version is new enough assuming newer cl's diag on 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37316] New: [CFI] LLVM should die (and doesn't) when implicit CFI blacklist file cannot be found.
https://bugs.llvm.org/show_bug.cgi?id=37316 Bug ID: 37316 Summary: [CFI] LLVM should die (and doesn't) when implicit CFI blacklist file cannot be found. Product: compiler-rt Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: cmt...@google.com CC: llvm-bugs@lists.llvm.org The CFI blacklist file, /usr/lib/clang//share/cfi_blacklist.txt is necessary for correct code generation. Although it can be specified with the -fsaniter-blacklist option, it usually is just used implicitly, without that option. If CFI is enabled and that file is missing, LLVM should die (but it does not). This is bad as it can lead to generated binaries that fail with CFI checks that are already known to be bad (blacklisted). -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37317] New: ModuleList::FindGlobalVariables fails with append=false
https://bugs.llvm.org/show_bug.cgi?id=37317 Bug ID: 37317 Summary: ModuleList::FindGlobalVariables fails with append=false Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: t...@tromey.com CC: llvm-bugs@lists.llvm.org In my Rust work I found that ModuleList::FindGlobalVariables will not work properly when passed append=false. The issue comes because SymbolFileDWARF::FindGlobalVariables does: // If we aren't appending the results to this list, then clear the list if (!append) variables.Clear(); So, if there are multiple modules, later ones will erase the results from earlier ones. A simple fix would be to change ModuleList::FindGlobalVariables to do something like: if (!append) variables.Clear(); ... (*pos)->FindGlobalVariables(name, nullptr, true, max_matches, variable_list); That is, always pass append=true to the callees. I would submit a patch for this but I don't know how to write a test case. So, I thought I'd file this instead. I'm also going to fix it in my tree. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37318] New: Denormalized Floating-point Causes Bad Stream State
https://bugs.llvm.org/show_bug.cgi?id=37318 Bug ID: 37318 Summary: Denormalized Floating-point Causes Bad Stream State Product: libc++ Version: 6.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: brett.bernst...@gmail.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 20255 --> https://bugs.llvm.org/attachment.cgi?id=20255&action=edit Source code demonstrates issue. On clang it never outputs "ok 2" When a denormalized floating-point number is handled by a stream it results in a bad stream state. Code attached, but the following link also has the issue: https://wandbox.org/permlink/E4xV1p0YUdh36LhH -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37319] New: wrong code at -O2 for trivial_abi class that inspects its own "this" pointer
https://bugs.llvm.org/show_bug.cgi?id=37319 Bug ID: 37319 Summary: wrong code at -O2 for trivial_abi class that inspects its own "this" pointer Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: arthur.j.odw...@gmail.com CC: llvm-bugs@lists.llvm.org cat > test.cc < #include #define TRIVIAL_ABI __attribute__((trivial_abi)) template class TRIVIAL_ABI trivial_offset_ptr { intptr_t value_; public: trivial_offset_ptr(T *p) : value_((const char*)p - (const char*)this) {} trivial_offset_ptr(const trivial_offset_ptr& rhs) : value_((const char*)rhs.get() - (const char*)this) {} T *get() const { return (T *)((const char *)this + value_); } trivial_offset_ptr& operator=(const trivial_offset_ptr& rhs) { value_ = ((const char*)rhs.get() - (const char*)this); return *this; } trivial_offset_ptr& operator+=(int diff) { value_ += (diff * sizeof (T)); return *this; } }; trivial_offset_ptr incr(trivial_offset_ptr p) { p += 1; return p; } int main() { int a[10]; trivial_offset_ptr op = &a[4]; trivial_offset_ptr top = &a[4]; top = incr(top); assert(top.get() == &a[5]); } EOF clang++ -std=c++17 -O1 test.cc -o a.out ./a.out # works great! clang++ -std=c++17 -O2 test.cc -o a.out ./a.out Assertion failed: (top.get() == &a[5]), function main, file test.cc, line 34. Abort trap: 6 This is super sneaky UB-ful code in theory, I'm sure, but IMHO Clang is still doing something not-conservative-enough here. Especially, notice that if you remove the unused local variable `op` from `main`, the assertion will pass. Put the unused variable back, and the assertion will fail. Documentation for [[trivial_abi]] is here. It does not mention any caveats about "don't implement offset_ptr with this attribute." I would grudgingly accept that outcome if it were proposed (but I'd rather the code Just Work). https://clang.llvm.org/docs/AttributeReference.html#trivial-abi-clang-trivial-abi P.S. I am aware that [[trivial_abi]] is super new, and I love it, and I don't mean to be harsh at all in this first corner-case bug filed against it. :) -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 35506] [Analyzer- Loop Widen] Assertion `!InitValWithAdjustments.getAs() || Loc::isLocType(Result->getType()) || Result->getType()->isMemberPointerType()' failed.
https://bugs.llvm.org/show_bug.cgi?id=35506 Matt Davis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||matthew.da...@sony.com --- Comment #3 from Matt Davis --- It seems that this bug has been fixed b r330095, I am going to mark the status of this as fixed. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 8119 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in clang::StmtVisitorBase::Visit
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, llvm-b...@lists.llvm.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-05-03 Type: Bug New issue 8119 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in clang::StmtVisitorBasebool>::Visit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8119 Detailed report: https://oss-fuzz.com/testcase?key=5374688455819264 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fff774ac7c0 Crash State: clang::StmtVisitorBasebool>::Visit Evaluate IntExprEvaluator::VisitCastExpr Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201711160610:201712080609 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5374688455819264 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37229] Miscompile with the PPC backend after r329047
https://bugs.llvm.org/show_bug.cgi?id=37229 Max Kazantsev changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #22 from Max Kazantsev --- Thanks Nemanja! I have returned the reverted patch as https://reviews.llvm.org/rL331427. Closing this one as fixed. Please let me know if anyone sees this problem again. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs