[llvm-bugs] Issue 4609 in oss-fuzz: llvm: Stack-overflow in Evaluate
Updates: Status: WontFix Comment #5 on issue 4609 by ClusterFuzz-External: llvm: Stack-overflow in Evaluate https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4609#c5 ClusterFuzz testcase 4629918072700928 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] Issue 4816 in oss-fuzz: llvm: Stack-overflow in clang::CharLiteralParser::CharLiteralParser
Updates: Status: WontFix Comment #4 on issue 4816 by ClusterFuzz-External: llvm: Stack-overflow in clang::CharLiteralParser::CharLiteralParser https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4816#c4 ClusterFuzz testcase 4971130851950592 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 36473] New: Scanning fis-gtm produces multiple cores
https://bugs.llvm.org/show_bug.cgi?id=36473
Bug ID: 36473
Summary: Scanning fis-gtm produces multiple cores
Product: clang
Version: 4.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: amul.s...@fisglobal.com
CC: llvm-bugs@lists.llvm.org
I am using the Clang SCA to analyze the source code of FIS GT.M (fis-gtm.com)
and have run into a number of failures that result in analyzer core dumps. I
understand that the bug report in this email will need to be re-entered into
the bug tracker, but since there will be some turn-around time between getting
access to the bug tracker and me needing to write the bug report, I thought it
would prudent to type up the report now.
Thanks,
Amul Shah
Host platform:
$ lsb_release -d
Description:Fedora release 26 (Twenty Six)
Clang version (default for Fedora):
$ clang --version
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Source Code:
https://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/V6.3-003A/
Steps to reproduce:
1. Download sources and install dependencies listed in the README (on
Debian/Ubuntu installing fis-gtm will install all of the dependencies)
2. Execute the following from the source directory
mkdir build && cd build
export PATH "${PATH}:/usr/libexec"
set utflocale = `locale -a | gawk
'BEGIN{IGNORECASE=1}/en_us.utf-*8/{print;exit}'`
setenv LANG C
setenv LC_ALL "${utflocale}"
setenv LC_COLLATE C
setenv CCC_CC clang
setenv CCC_CXX clang++
set ccc_analyzer=`which ccc-analyzer`
cmake -DCMAKE_C_COMPILER=$ccc_analyzer -DCMAKE_ASM_COMPILER=gcc
-DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_FLAGS_DEBUG="-DSTATIC_ANALYSIS
-DSTATIC_ANALYSIS_NORETURN" -DGTM_ENABLE_DEBUG=0 ..
echo "Building in ${PWD}"
scan-build --status-bugs -analyze-headers -stats -disable-checker
deadcode.DeadStores -analyzer-config stable-report-filename=true -o ${PWD} make
-j 8
--
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 6505 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in Evaluate
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-02-22 Type: Bug New issue 6505 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in Evaluate https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6505 Detailed report: https://oss-fuzz.com/testcase?key=5644518255755264 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: 0x7ffe33b77e80 Crash State: Evaluate IntExprEvaluator::VisitUnaryOperator clang::StmtVisitorBasebool>::Visit Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712090607:201712100011 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5644518255755264 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 6504 in oss-fuzz: llvm/clang-format-fuzzer: Stack-overflow in clang::format::AnnotatingParser::parseAngle
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-02-22 Type: Bug New issue 6504 by ClusterFuzz-External: llvm/clang-format-fuzzer: Stack-overflow in clang::format::AnnotatingParser::parseAngle https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6504 Detailed report: https://oss-fuzz.com/testcase?key=5643341178863616 Project: llvm Fuzzer: libFuzzer_llvm_clang-format-fuzzer Fuzz target binary: clang-format-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe1cd22e38 Crash State: clang::format::AnnotatingParser::parseAngle clang::format::AnnotatingParser::consumeToken Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802060728:201802070205 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5643341178863616 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36423, which changed state. Bug 36423 Summary: r324100 breaks lld on OpenBSD https://bugs.llvm.org/show_bug.cgi?id=36423 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |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] [Bug 36423] r324100 breaks lld on OpenBSD
https://bugs.llvm.org/show_bug.cgi?id=36423 Hans Wennborg changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Hans Wennborg --- Sorry, I hadn't seen that there was follow-up discussion (for reference, this is on the D42825 mailing list thread). We're too late in the 6.0.0 process to mess around with this. In r325759 I've reverted the branch back to where we were at branch point, i.e. the flag is spelled the same as in lld 5.0.1. Future changes can be done on trunk and shipped in lld 7. (As a parenthesis to the discussion, note that Clang also supports the -nopie spelling, and passing it along spelled like that to the linker on OpenBSD.) -- 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 6508 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: isa(Val) && "cast() argument of incompatible type!"
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-02-22 Type: Bug New issue 6508 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-loop_vectorize: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6508 Detailed report: https://oss-fuzz.com/testcase?key=5747209996861440 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-loop_vectorize Fuzz target binary: llvm-opt-fuzzer--x86_64-loop_vectorize Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Val) && "cast() argument of incompatible type!" llvm::InnerLoopVectorizer::buildScalarSteps llvm::InnerLoopVectorizer::widenIntOrFpInduction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802190622:201802200626 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5747209996861440 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36292, which changed state. Bug 36292 Summary: Invalid PPC CTR loop with llc on powerpc64le-unknown-linux-gnu https://bugs.llvm.org/show_bug.cgi?id=36292 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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] [Bug 36292] Invalid PPC CTR loop with llc on powerpc64le-unknown-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=36292 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Hans Wennborg --- (In reply to Nemanja Ivanovic from comment #7) > Committed revision 325739. > > Hans, if you don't mind, please backport to 6.0. > Sorry about the late submission. Merged in r325767. Thanks! -- 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 36474] New: Assertion failure in RegionStoreManager::getBinding
https://bugs.llvm.org/show_bug.cgi?id=36474
Bug ID: 36474
Summary: Assertion failure in RegionStoreManager::getBinding
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: ale...@google.com
CC: ekarpen...@apple.com, llvm-bugs@lists.llvm.org
$ cat test-RegionStoreManager__getBinding.c
a;
b(void **c) {
*c = a;
int *d;
b(&d);
*d;
}
$ clang-tidy -checks=-*,clang-analyzer* test-RegionStoreManager__getBinding.c
--
assert.h assertion failed at
llvm/tools/clang/lib/StaticAnalyzer/Core/RegionStore.cpp:1408 in
clang::ento::SVal (anonymous
namespace)::RegionStoreManager::getBinding(RegionBindingsConstRef,
clang::ento::Loc, clang::QualType): !T->isVoidType() && "Attempting to
dereference a void pointer!"
@ 0x564dda45a0e6 __assert_fail
@ 0x564dd8ecd09d (anonymous
namespace)::RegionStoreManager::getBinding()
@ 0x564dd8ec6ba4 (anonymous
namespace)::RegionStoreManager::getBinding()
@ 0x564dd8f04bf8 clang::ento::ProgramState::getSVal()
@ 0x564dd841cd30 clang::ento::check::Location::_checkLocation<>()
@ 0x564dd8f43b1c clang::ento::CheckerManager::runCheckersForLocation()
@ 0x564dd8f5ea9f clang::ento::ExprEngine::evalLocation()
@ 0x564dd8f5ece4 clang::ento::ExprEngine::evalLoadCommon()
@ 0x564dd8f5de77 clang::ento::ExprEngine::evalLoad()
@ 0x564dd8f7a97c clang::ento::ExprEngine::VisitCast()
@ 0x564dd8f5429b clang::ento::ExprEngine::Visit()
@ 0x564dd8f5179e clang::ento::ExprEngine::ProcessStmt()
@ 0x564dd8f5149b clang::ento::ExprEngine::processCFGElement()
@ 0x564dd8f72f85 clang::ento::CoreEngine::HandlePostStmt()
@ 0x564dd8f7223d clang::ento::CoreEngine::ExecuteWorkList()
@ 0x564dd7f9b9c3 (anonymous
namespace)::AnalysisConsumer::ActionExprEngine()
@ 0x564dd7f9b546 (anonymous namespace)::AnalysisConsumer::HandleCode()
@ 0x564dd7f858c4 (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 36032] After r313012, Assertion failed: (ExitCount != SE.getCouldNotCompute() && "Invalid loop count"), function generateOverflowCheck, file lib/Analysis/ScalarEvolutionExpander.cpp,
https://bugs.llvm.org/show_bug.cgi?id=36032 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Hans Wennborg --- (In reply to Silviu Baranga from comment #9) > Yes, let's merge r325687 for 6.0.0. Merged in r325773. Thanks! -- 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 35804] [meta] 6.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=35804 Bug 35804 depends on bug 36032, which changed state. Bug 36032 Summary: After r313012, Assertion failed: (ExitCount != SE.getCouldNotCompute() && "Invalid loop count"), function generateOverflowCheck, file lib/Analysis/ScalarEvolutionExpander.cpp, line 2126. https://bugs.llvm.org/show_bug.cgi?id=36032 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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] [Bug 36475] New: Unexpected change in layout behaviour for synthetic sections in scripts
https://bugs.llvm.org/show_bug.cgi?id=36475 Bug ID: 36475 Summary: Unexpected change in layout behaviour for synthetic sections in scripts Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: llvm-bugs@lists.llvm.org r325763 led to a change in how synthetic sections behave in layout when there are no non-empty input sections in their linker script entry, but when there are other commands, e.g. BYTE or symbol assignments. I'll post on https://reviews.llvm.org/D43574 to highlight the bit of offending code for 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 36476] New: [InstCombine] Instcombine deletes call of 'new' function that has side effects after r325630
https://bugs.llvm.org/show_bug.cgi?id=36476
Bug ID: 36476
Summary: [InstCombine] Instcombine deletes call of 'new'
function that has side effects after r325630
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
This test fails at with wrong result after r325630:
= nice.cpp
#include
#include
extern void *operator new(size_t size)
{
printf("Happy ending\n");
exit(0);
return malloc(size);
}
struct S { int a;};
int main ()
{
S *s = new S;
printf("Bad ending\n");
printf("%x\n", s -> a);
return 0;
}
===
>>> clang -v
clang version 7.0.0 (trunk 325762)
Target: x86_64-unknown-linux-gnu
Thread model: posix
...
>>> clang -o nice.exe nice.cpp -O0
>>> ./nice.exe
Happy ending
>>> clang -o nice.exe nice.cpp -O1
>>> ./nice.exe
Bad ending
Illegal instruction (core dumped)
>>> clang -o nice.exe nice.cpp -mllvm -opt-bisect-limit :
BISECT: running pass (15) Simplify the CFG on function (_Znwm)
-> Happy ending
BISECT: running pass (16) Combine redundant instructions on function (main)
-> Bad ending
nice-before.ll ===
...
; Function Attrs: nobuiltin uwtable
define dso_local noalias i8* @_Znwm(i64) local_unnamed_addr #0 {
%2 = call i32 @puts(i8* getelementptr inbounds ([13 x i8], [13 x i8]* @str,
i64 0, i64 0))
call void @exit(i32 0) #5
unreachable
}
; Function Attrs: norecurse uwtable
define dso_local i32 @main() local_unnamed_addr #3 {
%1 = call i8* @_Znwm(i64 undef) #6
%2 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([12 x i8], [12 x
i8]* @.str.1, i32 0, i32 0))
%3 = getelementptr inbounds %struct.S, %struct.S* undef, i32 0, i32 0
%4 = load i32, i32* %3, align 4, !tbaa !2
%5 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x
i8]* @.str.2, i32 0, i32 0), i32 %4)
ret i32 0
}
...
===
>>> opt nice-before.ll -instcombine -o nice-after.ll -S
nice-after.ll ===
...
; Function Attrs: norecurse uwtable
define dso_local i32 @main() local_unnamed_addr #3 {
%puts = call i32 @puts(i8* getelementptr inbounds ([11 x i8], [11 x i8]*
@str.1, i64 0, i64 0))
store i32 undef, i32* null, align 536870912
%1 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8], [4 x
i8]* @.str.2, i64 0, i64 0), i32 undef)
ret i32 0
}
...
===
This started giving wrong behavior after r325630
[https://reviews.llvm.org/rL325630]
---
r325630 | d0k | 2018-02-20 23:00:33 +0100 (Tue, 20 Feb 2018) | 5 lines
[MemoryBuiltins] Check nobuiltin status when identifying calls to free.
This is usually not a problem because this code's main purpose is
eliminating unused new/delete pairs. We got deletes of nullptr or
nobuiltin deletes of builtin new wrong though.
---
--
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 36469] std::invoke of std::optional::has_value pointer-to-member-function fails, due to its class type being a private base.
https://bugs.llvm.org/show_bug.cgi?id=36469 David Blaikie 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] [Bug 35650] [mc] Zero divider is not handled for modulo
https://bugs.llvm.org/show_bug.cgi?id=35650 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||325810 --- Comment #4 from Simon Pilgrim --- rL325810 -- 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 36477] New: clang-analyzer-core.uninitialized.Assign: False positive with reinterpret_cast
https://bugs.llvm.org/show_bug.cgi?id=36477
Bug ID: 36477
Summary: clang-analyzer-core.uninitialized.Assign: False
positive with reinterpret_cast
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: r...@eatnumber1.com
CC: llvm-bugs@lists.llvm.org
I've been encountering a case where Clang Static Analyzer raises
clang-analyzer-core.uninitialized.Assign. I've narrowed down the culprit code
to the following sample case:
struct myint {
int d;
};
struct foo {
myint a;
};
int myfn1() {
foo myfoo {5};
const unsigned char *a = reinterpret_cast(&myfoo.a);
char ret = a[1];
return ret;
}
The warning generated is:
$ scan-build clang++ -std=c++11 -c -O0 ~/a.cc
scan-build: Using '/usr/bin/clang' for static analysis
/usr/local/google/home/eatnumber1/a.cc:12:3: warning: Assigned value is garbage
or undefined
char ret = a[1];
^~~~
1 warning generated.
scan-build: 1 bugs found.
scan-build: Run 'scan-view /tmp/scan-build-2017-10-13-151811-27304-1' to
examine bug reports.
If I change `struct foo` to the following:
struct foo {
int a;
};
then the warning is not emitted.
What's going on here?
--
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 6515 in oss-fuzz: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: (VTy->isFirstClassType() || VTy->isVoidTy() || VTy->isStructTy()) && "invalid Ca
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-02-22 Type: Bug New issue 6515 by ClusterFuzz-External: llvm/llvm-opt-fuzzer--x86_64-gvn: ASSERT: (VTy->isFirstClassType() || VTy->isVoidTy() || VTy->isStructTy()) && "invalid Ca https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6515 Detailed report: https://oss-fuzz.com/testcase?key=5667137579384832 Project: llvm Fuzzer: libFuzzer_llvm_llvm-opt-fuzzer--x86_64-gvn Fuzz target binary: llvm-opt-fuzzer--x86_64-gvn Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: (VTy->isFirstClassType() || VTy->isVoidTy() || VTy->isStructTy()) && "invalid Ca llvm::Value::Value llvm::BitcodeReaderValueList::getConstantFwdRef Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802050757:201802060728 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5667137579384832 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 36478] New: Make lld-link.exe detect that the result file is in use and that linking will fail.
https://bugs.llvm.org/show_bug.cgi?id=36478 Bug ID: 36478 Summary: Make lld-link.exe detect that the result file is in use and that linking will fail. Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: p...@google.com CC: llvm-bugs@lists.llvm.org When building chrome (and I have chrome.exe running), linking completes and fails when the result is about to be written to disk: [519/542] LINK(DLL) chrome.dll chrome.dll.lib chrome.dll.pdb FAILED: chrome.dll chrome.dll.lib chrome.dll.pdb C:/python_27_amd64/files/python.exe ../../build/toolchain/win/tool_wrapper.py link-wrapper environment.x86 False ../../third_party/llvm-build/Release+Asserts/bin/lld-link.exe /nologo /IMPLIB:./chrome.dll.lib /DLL /OUT:./chrome.dll /PDB:./chrome.dll.pdb @./chrome.dll.rsp ..\..\third_party\llvm-build\Release+Asserts\bin\lld-link.exe: error: failed to write the output file: permission denied [538/542] CXX obj/chrome/test/browser_tests/better_session_restore_browsertest.obj Since linking can take minutes it'd be nice if this case could (best-effort) be caught on startup rather than when all work is done. -- 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 36476] [InstCombine] Instcombine deletes call of 'new' function that has side effects after r325630
https://bugs.llvm.org/show_bug.cgi?id=36476 Richard Smith changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED CC||richard-l...@metafoo.co.uk --- Comment #1 from Richard Smith --- C++ [expr.new]p10 (http://eel.is/c++draft/expr.new#10) explicitly permits this optimization: "An implementation is allowed to omit a call to a replaceable global allocation function ([new.delete.single], [new.delete.array]). When it does so, the storage is instead provided by the implementation" If you want to observe side-effects of your '::operator new(size_t)' implementation (eg, when writing tests for your allocator), you need to make a regular function call, rather than using a new-expression. LLVM will not delete the 'operator new' call here: S *s = new (::operator new(sizeof(S))) S; -- 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 36479] New: libc++'s , , , provide wrong overload sets for abs
https://bugs.llvm.org/show_bug.cgi?id=36479 Bug ID: 36479 Summary: libc++'s , , , provide wrong overload sets for abs Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: richard-l...@metafoo.co.uk CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com libc++ does not implement the resolution of LWG issue 2192: https://cplusplus.github.io/LWG/issue2192 This results in the wrong value being produced for uses of abs() after only one of math.h / stdlib.h is included. -- 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 6166 in oss-fuzz: llvm: Stack-overflow in clang::Lexer::LexTokenInternal
Updates: Status: WontFix Comment #1 on issue 6166 by ClusterFuzz-External: llvm: Stack-overflow in clang::Lexer::LexTokenInternal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6166#c1 ClusterFuzz testcase 6512758343335936 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 36480] New: Option "-fpic" has no effection with option "-mcmodel=large"
https://bugs.llvm.org/show_bug.cgi?id=36480
Bug ID: 36480
Summary: Option "-fpic" has no effection with option
"-mcmodel=large"
Product: clang
Version: 5.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: pan...@gmail.com
CC: llvm-bugs@lists.llvm.org
~$ cat x.c
extern void ();
void x()
{
();
}
~$ clang -mcmodel=large -fpic -S x.c
~$ grep x.s
movabsq $, %rax
--
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 36481] New: Reassociation messes up SLPVectorizer reduction
https://bugs.llvm.org/show_bug.cgi?id=36481 Bug ID: 36481 Summary: Reassociation messes up SLPVectorizer reduction Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: timshe...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 19931 --> https://bugs.llvm.org/attachment.cgi?id=19931&action=edit Test Running `opt -S -slp-vectorizer $TEST_FILE`, the function gets SLP-vectorized; Running `opt -S -reassociate -slp-vectorizer $TEST_FILE`, the function doesn't get SLP-vectorized. This is because the reassociation pass re-associates instructions like `acc = add ith_element, acc` to `acc = add acc, ith_element`, but didn't re-assocate the first instruction `acc = add first_element, second_element` to `acc = add second_element, first_element`. However, as add is associative, a smarter SLP vectorizer could have ignored the associations and vectorize the unordered adds anyway. I'm not sure where to put the fix on. -- 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 36482] New: Missing rematerialization of a trival computation
https://bugs.llvm.org/show_bug.cgi?id=36482
Bug ID: 36482
Summary: Missing rematerialization of a trival computation
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: eugeni.stepa...@gmail.com
CC: llvm-bugs@lists.llvm.org
In the following example instead of rematerializing "add FP, #imm" after a
call, regalloc chooses to assign it to a callee-saved register, generating lots
of extra spills.
It appears that LLVM only ever remats COPY instructions (in RegisterCoalescer).
Is this a missing optimization? Where would it be implemented? LiveInterval
splitting in regalloc? In this case regalloc does not even attempt to split
because the function entry is not hot enough (RAGreedy::initializeCSRCost()
says that CSRCost == (5 / (1<<14)) ~== 0, so CSRs are free).
This is not AArch64-specific, very similar code is generated on X86.
$ cat 1.c
long p[6];
void use(long, long, long, long, long, long);
void f() {
long base = (long)__builtin_frame_address(0);
long a = base + 1;
long b = base + 2;
long c = base + 3;
long d = base + 4;
long e = base + 5;
long f = base + 6;
// Here a..f need to be in fixed, non-callee-saved regs, but they are also
// used after the call. Prefer rematerialing to allocating a callee-save
// register?
use(a, b, c, d, e, f);
p[0] = a;
p[1] = b;
p[2] = c;
p[3] = d;
p[4] = e;
p[5] = f;
return;
}
$ bin/clang 1.c -target aarch64-linux -O3 -c && bin/llvm-objdump -d -r 1.o
f:
0: f8 5f bc a9 stp x24, x23, [sp, #-64]!
4: fd 7b 03 a9 stp x29, x30, [sp, #48]
8: fd c3 00 91 add x29, sp, #48
c: a0 07 00 91 add x0, x29, #1
10: a1 0b 00 91 add x1, x29, #2
14: a2 0f 00 91 add x2, x29, #3
18: a3 13 00 91 add x3, x29, #4
1c: a4 17 00 91 add x4, x29, #5
20: a5 1b 00 91 add x5, x29, #6
24: f6 57 01 a9 stp x22, x21, [sp, #16]
28: f4 4f 02 a9 stp x20, x19, [sp, #32]
2c: b3 07 00 91 add x19, x29, #1
30: b4 0b 00 91 add x20, x29, #2
34: b5 0f 00 91 add x21, x29, #3
38: b6 13 00 91 add x22, x29, #4
3c: b7 17 00 91 add x23, x29, #5
40: b8 1b 00 91 add x24, x29, #6
44: 00 00 00 94 bl #0
0044: R_AARCH64_CALL26 use
48: 08 00 00 90 adrpx8, #0
0048: R_AARCH64_ADR_PREL_PG_HI21 p
4c: 08 01 00 91 add x8, x8, #0
004c: R_AARCH64_ADD_ABS_LO12_NCp
50: 13 51 00 a9 stp x19, x20, [x8]
54: 15 59 01 a9 stp x21, x22, [x8, #16]
58: fd 7b 43 a9 ldp x29, x30, [sp, #48]
5c: f4 4f 42 a9 ldp x20, x19, [sp, #32]
60: f6 57 41 a9 ldp x22, x21, [sp, #16]
64: 17 61 02 a9 stp x23, x24, [x8, #32]
68: f8 5f c4 a8 ldp x24, x23, [sp], #64
6c: c0 03 5f d6 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] Issue 6518 in oss-fuzz: llvm: Stack-overflow in EvaluateValue
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-02-23 Type: Bug New issue 6518 by ClusterFuzz-External: llvm: Stack-overflow in EvaluateValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6518 Detailed report: https://oss-fuzz.com/testcase?key=5734540648644608 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffc14587ee0 Crash State: EvaluateValue Sanitizer: address (ASAN) Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5734540648644608 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 36483] New: cfi-icall broken for available_externally functions
https://bugs.llvm.org/show_bug.cgi?id=36483 Bug ID: 36483 Summary: cfi-icall broken for available_externally functions Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Interprocedural Optimizations Assignee: unassignedb...@nondot.org Reporter: v...@tsyrklevich.net CC: llvm-bugs@lists.llvm.org A change [1] to ThinLTO to mark non-prevailing values as dead (and later drop dead symbols) has broken how LowerTypeTests handles available_externally functions. The LowerTypeTests pass uses liveness to determine which functions to emit cfi-icall thunks for to avoid avoid emitting thunks for unused functions. Because of the change in [1], available_externally functions are marked not live and LowerTypeTests does not emit thunks for them even when they are actually used. [1] https://reviews.llvm.org/D42107 -- 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 36484] New: Assertion failure with GVNHoist: Assertion `MSSA->dominates(NewDef, FirstDef) && "Should have dominated the new access"' failed.
https://bugs.llvm.org/show_bug.cgi?id=36484
Bug ID: 36484
Summary: Assertion failure with GVNHoist: Assertion
`MSSA->dominates(NewDef, FirstDef) && "Should have
dominated the new access"' failed.
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: efrie...@codeaurora.org
CC: dber...@dberlin.org, hiradi...@msn.com,
llvm-bugs@lists.llvm.org
Testcase (crashes with "opt -gvn-hoist"):
target datalayout = "e-m:e-p:32:32-i64:64-v128:64:128-a:0:32-n32-S64"
define void @f(i8* %p) {
entry:
switch i4 undef, label %if.then30 [
i4 4, label %if.end
i4 0, label %if.end
]
if.end:
br label %if.end19
if.end19:
br i1 undef, label %e, label %e.thread
e.thread:
store i8 0, i8* %p, align 4
br label %if.then30
if.then30:
call void @g()
unreachable
e:
store i8 0, i8* %p, align 4
unreachable
}
declare void @g()
The issue is related to the MemoryPhi in the block if.then30.
MemorySSAUpdater::moveTo erases the store in the block e.thread, then erases
the MemoryPHI in if.then30 because it's trivial (temporarily), then tries to
insert a def in if.end19. fixupDefs then asserts that if.end19 dominates
if.then30, which is not true.
Not sure what the right fix is here.
--
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 36485] New: Crash when compiling LLVM IR with tons of musttail calls
https://bugs.llvm.org/show_bug.cgi?id=36485 Bug ID: 36485 Summary: Crash when compiling LLVM IR with tons of musttail calls Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: fe...@indutny.com CC: llvm-bugs@lists.llvm.org Created attachment 19932 --> https://bugs.llvm.org/attachment.cgi?id=19932&action=edit LLVM IR file 0 clang-5.00x0001075c31e7 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 clang-5.00x0001075c26ea llvm::sys::RunSignalHandlers() + 83 2 clang-5.00x0001075c360e SignalHandler(int) + 239 3 libsystem_platform.dylib 0x7fff784cef5a _sigtramp + 26 4 libsystem_platform.dylib 00 _sigtramp + 2276659392 5 clang-5.00x000107553049 getCommonReturnValue(llvm::ReturnInst*, llvm::CallInst*) + 120 6 clang-5.00x00010755280a eliminateRecursiveTailCall(llvm::CallInst*, llvm::ReturnInst*, llvm::BasicBlock*&, bool&, llvm::SmallVectorImpl&, llvm::AAResults*) + 735 7 clang-5.00x0001075517b6 eliminateTailRecursion(llvm::Function&, llvm::TargetTransformInfo const*, llvm::AAResults*) + 2287 8 clang-5.00x00010729c2b4 llvm::FPPassManager::runOnFunction(llvm::Function&) + 276 9 clang-5.00x000106f7cb71 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 661 10 clang-5.00x00010729c7a5 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 579 11 clang-5.00x0001076e9df8 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr >) + 9714 12 clang-5.00x00010781fe97 clang::CodeGenAction::ExecuteAction() + 973 13 clang-5.00x0001079986db clang::FrontendAction::Execute() + 73 14 clang-5.00x00010796980b clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 625 15 clang-5.00x0001079c5a66 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2438 16 clang-5.00x0001066f0411 cc1_main(llvm::ArrayRef, char const*, void*) + 1169 17 clang-5.00x0001066eee70 main + 8127 18 libdyld.dylib0x7fff7824e145 start + 1 19 libdyld.dylib0x0033 start + 2279284463 Stack dump: 0. Program arguments: /usr/local/Cellar/llvm/5.0.1/bin/clang-5.0 -cc1 -triple x86_64-apple-macosx10.13.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name otherwise-skip.ll -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu penryn -target-linker-version 305 -dwarf-column-info -debugger-tuning=lldb -resource-dir /usr/local/Cellar/llvm/5.0.1/lib/clang/5.0.1 -Os -fdebug-compilation-dir /Users/findutnyy/Code/indutny/llparse -ferror-limit 19 -fmessage-length 178 -stack-protector 1 -fblocks -fobjc-runtime=macosx-10.13.0 -fencode-extended-block-signature -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /var/folders/7l/34nn743x7hv3pwhp4pjplxxc3kfgkf/T/otherwise-skip-5b8771.o -x ir test/tmp/otherwise-skip.ll 1. Per-module optimization passes 2. Running pass 'CallGraph Pass Manager' on module 'test/tmp/otherwise-skip.ll'. 3. Running pass 'Tail Call Elimination' on function '@llparse__n_start' clang-5.0: error: unable to execute command: Segmentation fault: 11 clang-5.0: error: clang frontend command failed due to signal (use -v to see invocation) clang version 5.0.1 (tags/RELEASE_501/final) Target: x86_64-apple-darwin17.0.0 Thread model: posix InstalledDir: /usr/local/opt/llvm/bin -- 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 36486] New: clang 5.0.1 coverage crashes on header only unit test project
https://bugs.llvm.org/show_bug.cgi?id=36486 Bug ID: 36486 Summary: clang 5.0.1 coverage crashes on header only unit test project Product: clang Version: 5.0 Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: sebastian.schnei...@sae-it.de CC: llvm-bugs@lists.llvm.org Created attachment 19933 --> https://bugs.llvm.org/attachment.cgi?id=19933&action=edit Preprocessed source and associated run script to reproduce crash when running #clang --coverage -g -Wall sample_tests.cpp -o testCov clang crashes and writes the following crash dump: 0x00014015D774 (0x0439AE08 0x00013F34061F 0x48665CAA4742 0x0 3280A90) 0x00014015F1CB (0x0200 0x07FE 0x00B50488 0x0 7FEFD841B3B) 0x0001402F2B27 (0x0046 0x 0x00B57C10 0x0 380) 0x0001402F1975 (0x 0x0001401153F5 0x00A7C7B0 0x0 001) 0x000140116091 (0x00A7CAA8 0x 0x48665CAA4742 0x0 000) 0x000140698371 (0x033D3340 0x00B5B4C0 0x00A7DCC0 0x0 0A7DBC0) 0x000141C71708 (0x000142777C61 0x000B 0x0008 0x0 001427764D3) 0x000140F829C2 (0x 0x 0x000D 0x0 0BE55D0) 0x0001409EFDDA (0x07FE0012 0x000142777CC3 0x0009 0x0 013) 0x0001409BB460 (0x00A7DFA8 0x0001409B601B 0x00BFF1F0 0x0 031) 0x000140A3027C (0x00B500010110 0x00BFD2F0 0x00BFB6C0 0x0 0B57C10) 0x00013F315E6B (0x07FEE35D69D8 0x00BD439B 0x00BD4300 0x0 101) 0x00013F314293 (0x 0x 0x 0x0 1D3AC6EABF74634) 0x000141C92D81 (0x 0x 0x 0x0 000) 0x778B59CD (0x 0x 0x 0x0 000), BaseThreadInitThunk() + 0xD bytes(s) 0x77A1383D (0x 0x 0x 0x0 000), RtlUserThreadStart() + 0x1D bytes(s) clang.exe: error: clang frontend command failed due to signal (use -v to see inv ocation) clang version 5.0.1 (tags/RELEASE_501/final) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: C:\Program Files\LLVM\bin clang.exe: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/b ugs/ and include the crash backtrace, preprocessed source, and associated run sc ript. clang.exe: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang.exe: note: diagnostic msg: C:\Users\SRS\AppData\Local\Temp\sample_tests-c2 39fb.cpp clang.exe: note: diagnostic msg: C:\Users\SRS\AppData\Local\Temp\sample_tests-c2 39fb.sh clang.exe: note: diagnostic msg: -- 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
