[llvm-bugs] Issue 3500 in oss-fuzz: llvm: Stack-overflow in llvm::APInt::tcShiftLeft
Updates: Status: WontFix Comment #2 on issue 3500 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm: Stack-overflow in llvm::APInt::tcShiftLeft https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3500#c2 ClusterFuzz testcase 4961379989585920 is flaky and no longer crashes, so closing issue. 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 34978] [InterleavedAccess] Crash with "(castIsValid(op, S, Ty) && "Invalid cast!")" on haswell
https://bugs.llvm.org/show_bug.cgi?id=34978 michael changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from michael --- Was fix and committed to revision rL316067 -- 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 34975] Out-of-bounds vector access in MipsLongBranch.cpp
https://bugs.llvm.org/show_bug.cgi?id=34975 Simon Dardis changed: What|Removed |Added Fixed By Commit(s)||316084 Resolution|--- |FIXED 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] [Bug 34310] libc++ does not correctly handle the regex: "[^\\W]
https://bugs.llvm.org/show_bug.cgi?id=34310 Marshall Clow (home) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marshall Clow (home) --- Fixed in revision 316095. -- 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 34991] New: clang crashes on valid code at -Os and above on x86_64-linux-gnu: Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"' failed
mp/polly/llvm/lib/IR/LegacyPassManager.cpp:1514:0 #16 0x0169684e RunPassOnSCC /home/su/software/tmp/polly/llvm/lib/Analysis/CallGraphSCCPass.cpp:156:0 #17 0x0169684e RunAllPassesOnSCC /home/su/software/tmp/polly/llvm/lib/Analysis/CallGraphSCCPass.cpp:424:0 #18 0x0169684e (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) /home/su/software/tmp/polly/llvm/lib/Analysis/CallGraphSCCPass.cpp:479:0 #19 0x01bda1ad runOnModule /home/su/software/tmp/polly/llvm/lib/IR/LegacyPassManager.cpp:1591:0 #20 0x01bda1ad llvm::legacy::PassManagerImpl::run(llvm::Module&) /home/su/software/tmp/polly/llvm/lib/IR/LegacyPassManager.cpp:1694:0 #21 0x0221f03e llvm::PrettyStackTraceString::~PrettyStackTraceString() /home/su/software/tmp/polly/llvm/include/llvm/Support/PrettyStackTrace.h:52:0 #22 0x0221f03e EmitAssembly /home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:788:0 #23 0x0221f03e clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) /home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/BackendUtil.cpp:1145:0 #24 0x02a2a2f7 std::unique_ptr >::~unique_ptr() /usr/include/c++/5/bits/unique_ptr.h:235:0 #25 0x02a2a2f7 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) /home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:292:0 #26 0x02bfdde8 void std::swap(bool&, bool&) /usr/include/c++/5/bits/move.h:187:0 #27 0x02bfdde8 clang::ParseAST(clang::Sema&, bool, bool) /home/su/software/tmp/polly/llvm/tools/clang/lib/Parse/ParseAST.cpp:161:0 #28 0x02a2978f clang::CodeGenAction::ExecuteAction() /home/su/software/tmp/polly/llvm/tools/clang/lib/CodeGen/CodeGenAction.cpp:1032:0 #29 0x025c9de6 clang::FrontendAction::Execute() /home/su/software/tmp/polly/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:897:0 #30 0x0259a3d6 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /home/su/software/tmp/polly/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:992:0 #31 0x02658472 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /home/su/software/tmp/polly/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:252:0 #32 0x00a899c8 cc1_main(llvm::ArrayRef, char const*, void*) /home/su/software/tmp/polly/llvm/tools/clang/tools/driver/cc1_main.cpp:221:0 #33 0x00a048c2 ExecuteCC1Tool /home/su/software/tmp/polly/llvm/tools/clang/tools/driver/driver.cpp:309:0 #34 0x00a048c2 main /home/su/software/tmp/polly/llvm/tools/clang/tools/driver/driver.cpp:388:0 #35 0x7f7ac91b0830 __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:325:0 #36 0x00a862e9 _start (/home/su/software/tmp/polly/llvm_build/bin/clang-6.0+0xa862e9) Stack dump: 0. Program arguments: /home/su/software/tmp/polly/llvm_build/bin/clang-6.0 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name small.c -mrelocation-model static -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -resource-dir /home/su/software/tmp/polly/llvm_build/lib/clang/6.0.0 -internal-isystem /usr/local/include -internal-isystem /home/su/software/tmp/polly/llvm_build/lib/clang/6.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -Os -fdebug-compilation-dir /home/su/projects/c-hunter-latest/test/compilertesting/scripts/speculative-execution/good/20171018-clangpolly-m32-O3-mllvm-polly-build-063035/delta -ferror-limit 19 -fmessage-length 116 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/small-28275b.o -x c small.c 1. parser at end of file 2. Per-module optimization passes 3. Running pass 'CallGraph Pass Manager' on module 'small.c'. 4. Running pass 'Combine redundant instructions' on function '@fn2' clang-6.0: error: unable to execute command: Aborted (core dumped) clang-6.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 6.0.0 (http://llvm.org/git/clang.git aed3a60e367b760d907954563f404458f9dbd478) (http://llvm.org/git/llvm.git cbd850f350921d0afdbdee35d5599b257cd1e8b3) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/su/bin clang-6.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-6.0: note: diagnostic msg: PLEASE ATTACH THE F
[llvm-bugs] [Bug 34992] New: Fatal error: Offset not zero at the point of scalar access
https://bugs.llvm.org/show_bug.cgi?id=34992
Bug ID: 34992
Summary: Fatal error: Offset not zero at the point of scalar
access
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: douglas_y...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Following r315984, one of our internal tests started to fail with the following
error from the compiler:
Offset not zero at the point of scalar access
%2 = load float, float* %india, align 4, !tbaa !6
!6 = !{!7, !9, i64 4}
4
fatal error: error in backend: Broken function found, compilation aborted!
You can reproduce this by compiling the following code with optimization’s
enabled:
Clang -cc1 -emit-obj -O2 reduced.cpp
Where reduced.cpp is the following code:
/* reduced.cpp */
class alpha;
namespace bravo {
namespace charlie {
void delta(alpha* element, char* name, float var);
}
namespace foxtrot {
class gulf { public: float hotel; float india; };
class juliet { public: gulf kilo[4]; };
}
namespace charlie {
class lima { public: bravo::foxtrot::juliet mike; };
void november( alpha* oscar, lima * papa ) {
alpha* quebec ;
delta(quebec, "romeo", papa->mike.kilo->india);
}
}
}
Thanks to Sunil for helping reduce this test for me.
--
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 34993] New: Syntax error for "new struct" inside conditional-expression
https://bugs.llvm.org/show_bug.cgi?id=34993
Bug ID: 34993
Summary: Syntax error for "new struct" inside
conditional-expression
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: zeratul...@hotmail.com
CC: llvm-bugs@lists.llvm.org
This code does not compile with clang:
struct A {};
struct A* b = (1 == 1) ? new struct A : new struct A;
The error message suggests that it's trying to parse "struct A :" as a
class-specifier, with the ":" starting the base-clause.
I believe that this is valid, at least since DR 2141 [1], which introduced the
"defining-type-specifier" grammar production. A "new-type-id" can only contain
a "type-specifier", not a "defining-type-specifier", and a "class-specifier" is
only valid as a "defining-type-specifier", so I don't believe clang should be
trying to parse a "class-specifier" at all. (Instead, the "struct A" should be
parsed as an "elaborate-type-specifier", which is a valid "type-specifier".)
(I'm not convinced that the code was invalid even before DR 2141 - I would have
thought that, having tried and failed to parse a "class-specifier", the
compiler would backtrack and try to parse an "elaborate-type-specifier" instead
- but I'm less confident about that.)
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2141
--
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 34994] New: sqrt(denormal float) gives -infinity with fast-math
https://bugs.llvm.org/show_bug.cgi?id=34994
Bug ID: 34994
Summary: sqrt(denormal float) gives -infinity with fast-math
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: newtonall...@gmail.com
CC: llvm-bugs@lists.llvm.org
Created attachment 19314
--> https://bugs.llvm.org/attachment.cgi?id=19314&action=edit
repro case
$ cat sqrt_denormal_fastmath.cc
#include
#include
__attribute__((noinline)) void print_sqrt(float val) {
const float root = sqrt(val);
std::cout << "sqrt(" << val << ") = " << root << std::endl;
}
int main(int argc, char** argv) {
print_sqrt(1e-34);
print_sqrt(1e-36);
print_sqrt(1e-38);
print_sqrt(1e-40);
print_sqrt(1e-42);
print_sqrt(1e-44);
print_sqrt(1e-46);
}
$ clang sqrt_denormal_fastmath.cc -O2 -std=c++11 -ffast-math
$ ./a.out
sqrt(1e-34) = 1e-17
sqrt(1e-36) = 1e-18
sqrt(1e-38) = -inf
sqrt(9.5e-41) = -inf
sqrt(1.00053e-42) = -inf
sqrt(9.80909e-45) = -inf
sqrt(0) = 0
The computed square root is correct for normalized floats and for zero, but is
completely wrong for denormal floats (negative infinity).
The square root for denormal floats should either be approximately correct, or
perhaps just rounded to zero.
The problem here is that sqrt is computed in fast-math mode on x86 using the
reciprocal square root instruction (rsqrtss), which returns infinity for an
input value of zero *or* any denormal float. The instructions after rsqrtss fix
up the input=zero case, but don't handle the input=denormal case.
Here's the generated assembly for the sqrt instruction above
(https://godbolt.org/g/hvbKPQ)
rsqrtss xmm3, xmm0
movaps xmm1, xmm0
movaps xmm4, xmm0
movss dword ptr [rsp + 12], xmm4 # 4-byte Spill
mulss xmm1, xmm3
movss xmm2, dword ptr [rip + .LCPI0_0] # xmm2 = mem[0],zero,zero,zero
mulss xmm2, xmm1
mulss xmm1, xmm3
addss xmm1, dword ptr [rip + .LCPI0_1]
mulss xmm1, xmm2
xorps xmm0, xmm0
cmpeqss xmm0, xmm4
andnps xmm0, xmm1
The last three instructions (xorps, cmpeqss, andnps) check if the input was
zero and set the output to zero if so. However, there's no check for whether
the input was denormal.
Relevant code:
- lib/Target/X86/X86ISelLowering.cpp: X86TargetLowering::getSqrtEstimate()
--
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 3675 in oss-fuzz: llvm/llvm-dwarfdump-fuzzer: ASSERT: getAddressSize() == DebugLineData.getAddressSize() && "Line table header and dat
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-18 New issue 3675 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-dwarfdump-fuzzer: ASSERT: getAddressSize() == DebugLineData.getAddressSize() && "Line table header and dat https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3675 Detailed report: https://oss-fuzz.com/testcase?key=5332386247081984 Project: llvm Fuzzer: libFuzzer_llvm_llvm-dwarfdump-fuzzer Fuzz target binary: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: getAddressSize() == DebugLineData.getAddressSize() && "Line table header and dat llvm::DWARFDebugLine::Prologue::parse llvm::DWARFContext::dump Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201708280446:201708291805 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5332386247081984 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 have questions for the OSS-Fuzz team, 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] Issue 3676 in oss-fuzz: llvm/clang-format-fuzzer: ASSERT: PPBranchLevel < (int)PPLevelBranchIndex.size()
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2017-10-18 New issue 3676 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/clang-format-fuzzer: ASSERT: PPBranchLevel < (int)PPLevelBranchIndex.size() https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3676 Detailed report: https://oss-fuzz.com/testcase?key=5663149194739712 Project: llvm Fuzzer: libFuzzer_llvm_clang-format-fuzzer Fuzz target binary: clang-format-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: PPBranchLevel < (int)PPLevelBranchIndex.size() clang::format::UnwrappedLineParser::conditionalCompilationEnd clang::format::UnwrappedLineParser::readToken Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201709130450:201709140449 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5663149194739712 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 have questions for the OSS-Fuzz team, 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 34995] New: Download page does not use HTTPS, makes provided signatures useless.
https://bugs.llvm.org/show_bug.cgi?id=34995 Bug ID: 34995 Summary: Download page does not use HTTPS, makes provided signatures useless. Product: Website Version: unspecified Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: General Website Assignee: unassignedb...@nondot.org Reporter: hakon@gmail.com CC: llvm-bugs@lists.llvm.org The LLVM download page (http://releases.llvm.org/download.html) does not use HTTPS. This makes the signatures provided useless, and makes it impossible to trust anything downloaded from the site. To fix: Ensure that download site is HTTPS and signed with a verified certificate. Related to https://bugs.llvm.org/show_bug.cgi?id=31474 -- 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 34995] Download page does not use HTTPS, makes provided signatures useless.
https://bugs.llvm.org/show_bug.cgi?id=34995 Anton Korobeynikov changed: What|Removed |Added CC||an...@korobeynikov.info Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Anton Korobeynikov --- The download page is available via https. Just give https://releases.llvm.org/download.html a try. -- 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 31474] llvm.org is not HTTPS-only, parts of llvm.org are not available over HTTPS, and the TLS certificate for llvm.org is bad
https://bugs.llvm.org/show_bug.cgi?id=31474 Anton Korobeynikov changed: What|Removed |Added CC||an...@korobeynikov.info Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Anton Korobeynikov --- The certificate was updated long 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 15653] HTTPS access to llvm.org gives 404 error
https://bugs.llvm.org/show_bug.cgi?id=15653 Daniel Holbert changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC||dholb...@mozilla.com --- Comment #7 from Daniel Holbert --- This was fixed at some point -- https://llvm.org/ isn't 404 anymore, but now shows the LLVM front page. (same as the insecure HTTP version of that URL) These sites mentioned in other comments all load fine for me, too: https://clang.llvm.org/ https://llvm.org/apt/ https://llvm.org/PR15653 (replacing "" with an actual bug number) -- 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 34853] lld segmentation faults on simple testcase
https://bugs.llvm.org/show_bug.cgi?id=34853 Rafael Ávila de Espíndola changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||rafael.espind...@gmail.com --- Comment #4 from Rafael Ávila de Espíndola --- This doesn't crash with trunk (and is asan clean). -- 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 34996] New: Possible incorrect message in file "libcxx/include/list" line 484
https://bugs.llvm.org/show_bug.cgi?id=34996
Bug ID: 34996
Summary: Possible incorrect message in file
"libcxx/include/list" line 484
Product: libc++
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: pet...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
While experimenting with a CodeSonar plugin we develop, we noticed a potential
bug in file "libcxx/include/list" line 484 (method
"__list_const_iterator::operator->()").
pointer operator->() const
{
#if _LIBCPP_DEBUG_LEVEL >= 2
_LIBCPP_ASSERT(__get_const_db()->__dereferenceable(this),
"Attempted to dereference a non-dereferenceable
list::iterator"); //HERE
#endif
return
pointer_traits::pointer_to(__ptr_->__as_node()->__value_);
}
Shouldn't the string message be "Attempted to dereference a non-dereferenceable
list::const_iterator" instead of the current one? The operation is for a
const_iterator (being in class __list_const_iterator). Moreover, for operator*
the message also mentions a "const_" iterator.
Thanks,
Petru Florin Mihancea
Note: The problem has been detected automatically via static analysis.
--
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 34997] New: clang-cl: /showIncludes doesn't work with /EP
https://bugs.llvm.org/show_bug.cgi?id=34997 Bug ID: 34997 Summary: clang-cl: /showIncludes doesn't work with /EP Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org $ /Users/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang-cl /P /EP foo.cc /Fiout.ii /showIncludes clang: warning: argument unused during compilation: '--show-includes' [-Wunused-command-line-argument] Works fine if I use just /P: $ /Users/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang-cl /P foo.cc /Fiout.ii /showIncludes Note: including file: /Users/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/lib/clang/6.0.0/include/stddef.h But I want preprocessor output without line directives. Is there a reason why this doesn't work, or is it just an oversight? -- 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 34998] New: [X86] Disassembler disassembles invalid gather/scatter that doesn't use VSIB
https://bugs.llvm.org/show_bug.cgi?id=34998 Bug ID: 34998 Summary: [X86] Disassembler disassembles invalid gather/scatter that doesn't use VSIB Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: llvm-bugs@lists.llvm.org This shouldn't disassemble echo "0xc4,0xe2,0xe9,0x92,0x08" | ./bin/llvm-mc -disassemble But does and generates vgatherdpd %xmm2, (%rax), %xmm1 Binutils has this same bug https://sourceware.org/bugzilla/show_bug.cgi?id=15229 so I checked to see if we did any better. -- 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 3679 in oss-fuzz: llvm/llvm-isel-fuzzer--aarch64-O2: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, llvm-b...@lists.llvm.org, v...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Stability-Memory-LeakSanitizer Engine-libfuzzer Proj-llvm Reported-2017-10-19 New issue 3679 by monor...@clusterfuzz-external.iam.gserviceaccount.com: llvm/llvm-isel-fuzzer--aarch64-O2: Direct-leak in llvm::BitcodeReaderValueList::getValueFwdRef https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3679 Detailed report: https://oss-fuzz.com/testcase?key=5792447943671808 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--aarch64-O2 Fuzz target binary: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Direct-leak Crash Address: Crash State: llvm::BitcodeReaderValueList::getValueFwdRef BitcodeReader::getValueTypePair BitcodeReader::parseFunctionBody Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5792447943671808 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 have questions for the OSS-Fuzz team, 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
