[llvm-bugs] [Bug 38592] New: TLS Support in -mcmodel=large
https://bugs.llvm.org/show_bug.cgi?id=38592
Bug ID: 38592
Summary: TLS Support in -mcmodel=large
Product: tools
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: TableGen
Assignee: unassignedb...@nondot.org
Reporter: umesh.kalap...@gmail.com
CC: llvm-bugs@lists.llvm.org
For the following case the llvm crash i.e
extern __thread int a ;
int main() {
a = 2;
}
;error
#clang -mcmodel=large -S test.c -v
clang -cc1 version 8.0.0 based upon LLVM 8.0.0svn default target
x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/home/bft/umesh/clang/build/lib/clang/8.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
fatal error: error in backend: Cannot select: t9: i64 = X86ISD::WrapperRIP
TargetGlobalTLSAddress:i64 0 [TF=10]
t8: i64 = TargetGlobalTLSAddress 0 [TF=10]
In function: main
clang-8: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
clang version 8.0.0 (trunk 339662) (llvm/trunk 339654)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/bft/umesh/clang/build/bin
clang-8: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.llvm.org/ and include the crash backtrace, preprocessed source,
and associated run script.
clang-8: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-8: note: diagnostic msg: /tmp/test-c04044.c
clang-8: note: diagnostic msg: /tmp/test-c04044.sh
clang-8: note: diagnostic msg:
Please note that the option "-ftls-model=local-exec" compiles the case ,we are
investigating the cause and any leads/comments from experts ,will help us to
narrow done the issue asap.
--
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 38593] New: -Watomic-alignment too eager?
https://bugs.llvm.org/show_bug.cgi?id=38593
Bug ID: 38593
Summary: -Watomic-alignment too eager?
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: mh+l...@glandium.org
CC: llvm-bugs@lists.llvm.org
$ cat < test.c
#include
uint64_t
loadSeqCst(uint64_t* addr) {
uint64_t v;
__atomic_load(addr, &v, __ATOMIC_SEQ_CST);
return v;
}
EOF
$ clang-7 -o test.o -c test.c -m32
test.c:6:3: warning: misaligned or large atomic operation may incur significant
performance penalty [-Watomic-alignment]
__atomic_load(addr, &v, __ATOMIC_SEQ_CST);
^
1 warning generated.
This seems too eager for a warning that is emitted without even passing a
-Wsomething on the command line.
--
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 38594] New: i686-apple-darwin target-cpu is i686 ?
https://bugs.llvm.org/show_bug.cgi?id=38594 Bug ID: 38594 Summary: i686-apple-darwin target-cpu is i686 ? Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Driver Assignee: unassignedclangb...@nondot.org Reporter: gonzalob...@gmail.com CC: llvm-bugs@lists.llvm.org echo | clang -### -E - --target=i686-apple-darwin produces: -target-cpu i686 Does that mean that the following CPU is used? https://github.com/llvm-mirror/llvm/blob/3b09b9e80ea336869ce855baa4c11b5cd762aa44/lib/Target/X86/X86.td#L460 def : Proc<"i686", [FeatureX87, FeatureSlowUAMem16, FeatureCMOV]>; Given that the first Apple machines using Intel CPUs were from the mid 2000s, and were using core CPUs with SSE3, I must ask, if this is correct, what is the reason for 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 38595] New: [Formatter/ObjC] Incorrect break before accessing a field of an output of a method expression
https://bugs.llvm.org/show_bug.cgi?id=38595
Bug ID: 38595
Summary: [Formatter/ObjC] Incorrect break before accessing a
field of an output of a method expression
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Formatter
Assignee: unassignedclangb...@nondot.org
Reporter: joles...@google.com
CC: djas...@google.com, kli...@google.com,
llvm-bugs@lists.llvm.org
Correct output:
= [ :
:].g;
clang-format -style='{ColumnLimit: 30}' file.m:
= [ :
:]
.g;
--
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 36437] [NewGVN] Seemingly incorrect transformation.
https://bugs.llvm.org/show_bug.cgi?id=36437 Jonas Paulsson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38580, which changed state. Bug 38580 Summary: Merge r339794 into the 7.0 branch: fixes ~2000 test failures for FreeBSD https://bugs.llvm.org/show_bug.cgi?id=38580 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 38580] Merge r339794 into the 7.0 branch: fixes ~2000 test failures for FreeBSD
https://bugs.llvm.org/show_bug.cgi?id=38580 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Merged in r339852. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38581, which changed state. Bug 38581 Summary: Merge r339166 into the 7.0 branch https://bugs.llvm.org/show_bug.cgi?id=38581 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 38581] Merge r339166 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=38581 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hans Wennborg --- Merged to 7.0 in r339853. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38585, which changed state. Bug 38585 Summary: Merge r339743 into the 7.0 branch https://bugs.llvm.org/show_bug.cgi?id=38585 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 38585] Merge r339743 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=38585 Hans Wennborg changed: What|Removed |Added CC||h...@chromium.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Hans Wennborg --- Merged in r339854. -- 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 38596] New: [Formatter/ObjC] Incorrect spaces when a element of an array literal is a method expression and a receiver is an array element
https://bugs.llvm.org/show_bug.cgi?id=38596 Bug ID: 38596 Summary: [Formatter/ObjC] Incorrect spaces when a element of an array literal is a method expression and a receiver is an array element Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: joles...@google.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Correct: = [[0] ]; Correct: = @[ [ ] ]; But clang-format fails when above constructions are combined: = @ [[ [0] ]]; Should be: = @[ [[0] ] ]; -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38533, which changed state. Bug 38533 Summary: Cannot use this version of ReplaceAllUsesWith! https://bugs.llvm.org/show_bug.cgi?id=38533 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 38533] Cannot use this version of ReplaceAllUsesWith!
https://bugs.llvm.org/show_bug.cgi?id=38533 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Hans Wennborg --- Merged r339533, r339535 and r339536 to 7.0 in r339855, r339856, r339857 respsectively. -- 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 38087] Power9: Assertion failure from llvm::PPCTargetLowering::DAGCombineBuildVector()
https://bugs.llvm.org/show_bug.cgi?id=38087 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||h...@chromium.org --- Comment #3 from Hans Wennborg --- (In reply to Nemanja Ivanovic from comment #2) > Fix in https://reviews.llvm.org/D49080 That landed in r339769 and I merged it to 7.0 in r339859. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38087, which changed state. Bug 38087 Summary: Power9: Assertion failure from llvm::PPCTargetLowering::DAGCombineBuildVector() https://bugs.llvm.org/show_bug.cgi?id=38087 What|Removed |Added Status|ASSIGNED|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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 38418, which changed state. Bug 38418 Summary: [SLP] "PHI nodes not grouped at top of basic block!" after "SLP Vectorizer" after r338380 https://bugs.llvm.org/show_bug.cgi?id=38418 What|Removed |Added Status|ASSIGNED|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 38418] [SLP] "PHI nodes not grouped at top of basic block!" after "SLP Vectorizer" after r338380
https://bugs.llvm.org/show_bug.cgi?id=38418 Hans Wennborg changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||h...@chromium.org Resolution|--- |FIXED --- Comment #3 from Hans Wennborg --- (In reply to Alexey Bataev from comment #2) > Fixed in r339166 And merged in r339853 -- 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 38597] New: Crash when building Firefox with LTO with clang 7.0 rc1
https://bugs.llvm.org/show_bug.cgi?id=38597 Bug ID: 38597 Summary: Crash when building Firefox with LTO with clang 7.0 rc1 Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mh+l...@glandium.org CC: llvm-bugs@lists.llvm.org This is what is printed out when it fails: PHI nodes not grouped at top of basic block! %703 = phi float [ undef, %606 ], [ undef, %610 ], [ undef, %658 ], [ %659, %666 ], [ undef, %625 ], [ undef, %619 ], [ undef, %613 ] label %699 LLVM ERROR: Broken function found, compilation aborted! #0 0x004cb2a4 PrintStackTraceSignalHandler(void*) (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x4cb2a4) #1 0x004c956e llvm::sys::RunSignalHandlers() (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x4c956e) #2 0x004cb4b2 SignalHandler(int) (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x4cb4b2) #3 0x7f7e5acbf0a0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0xf0a0) #4 0x018d35c7 llvm::BitcodeModule::getModuleImpl(llvm::LLVMContext&, bool, bool, bool) (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x18d35c7) #5 0x018da644 llvm::BitcodeModule::parseModule(llvm::LLVMContext&) (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x18da644) #6 0x00eec0da (anonymous namespace)::InProcessThinBackend::runThinLTOBackendThread(std::function > (unsigned int)>, std::function > (unsigned int)> (unsigned int, llvm::StringRef)>, unsigned int, llvm::BitcodeModule, llvm::ModuleSummaryIndex&, llvm::StringMap, std::equal_to, std::allocator >, llvm::MallocAllocator> const&, std::unordered_set, std::equal_to, std::allocator > const&, std::map, std::allocator > > const&, llvm::DenseMap, llvm::detail::DenseMapPair > const&, llvm::MapVector, llvm::detail::DenseMapPair >, std::vector, std::allocator > > >&, llvm::DenseMap const*>, llvm::DenseMapInfo, llvm::detail::DenseMapPair const*> > > const&)::'lambda'(std::function > (unsigned int)>)::operator()(std::function > (unsigned int)>) const (/builds/worker/workspace/build/src/clang/bin/ld.lld+0xeec0da) #7 0x00eea637 std::_Function_handler, std::equal_to, std::allocator >, llvm::MallocAllocator> const&, std::unordered_set, std::equal_to, std::allocator > const&, std::map, std::allocator > > const&, llvm::MapVector, llvm::detail::DenseMapPair >, std::vector, std::allocator > > >&)::'lambda'(llvm::BitcodeModule, llvm::ModuleSummaryIndex&, llvm::StringMap, std::equal_to, std::allocator >, llvm::MallocAllocator> const&, std::unordered_set, std::equal_to, std::allocator > const&, std::map, std::allocator > > const&, llvm::DenseMap, llvm::detail::DenseMapPair > const&, llvm::MapVector, llvm::detail::DenseMapPair >, std::vector, std::allocator > > >&, llvm::DenseMap const*>, llvm::DenseMapInfo, llvm::detail::DenseMapPair const*> > > const&) (llvm::BitcodeModule, std::reference_wrapper, std::reference_wrapper, std::equal_to, std::allocator >, llvm::MallocAllocator> const>, std::reference_wrapper, std::equal_to, std::allocator > const>, std::reference_wrapper, std::allocator > > const>, std::reference_wrapper, llvm::detail::DenseMapPair > const>, std::reference_wrapper, llvm::detail::DenseMapPair >, std::vector, std::allocator > > > >, std::reference_wrapper const*>, llvm::DenseMapInfo, llvm::detail::DenseMapPair const*> > > >)> >::_M_invoke(std::_Any_data const&) (/builds/worker/workspace/build/src/clang/bin/ld.lld+0xeea637) #8 0x01a46688 std::_Function_handler (), std::__future_base::_Task_setter, std::__future_base::_Result_base::_Deleter>, void> >::_M_invoke(std::_Any_data const&) (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x1a46688) #9 0x00517322 std::__future_base::_State_baseV2::_M_do_set(std::function ()>&, bool&) (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x517322) #10 0x7f7e5acbc8a0 __pthread_once_internal /build/eglibc-ZYONVs/eglibc-2.13/nptl/../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_once.S:108:0 #11 0x01a464db std::__future_base::_Task_state, std::allocator, void ()>::_M_run() (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x1a464db) #12 0x01a45f28 std::thread::_Impl >::_M_run() (/builds/worker/workspace/build/src/clang/bin/ld.lld+0x1a45f28) #13 0x01aa36a0 ~__shared_count /builds/worker/workspace/build/gcc-objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:665:0 #14 0x01aa36a0 ~__shared_ptr /builds/worker/workspace/build/gcc-objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr_base.h:914:0 #15 0x01aa36a0 ~shared_ptr /builds/worker/workspace/build/gcc-objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/shared_ptr.h:93:0 #16 0x01aa36a0 execute_native_thre
[llvm-bugs] [Bug 38588] XRay memory allocation may cause segfaults
https://bugs.llvm.org/show_bug.cgi?id=38588 Dean Michael Berris changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Dean Michael Berris --- Fixed in r339869. -- 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 38516] void MipsPassConfig::addPreEmit2() is defined but never used
https://bugs.llvm.org/show_bug.cgi?id=38516 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||339847 Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- Fixed at rL339847 -- 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 38598] New: Merge r339704 and r339805 to 7.0 branch: critical fixes for OpenMP
https://bugs.llvm.org/show_bug.cgi?id=38598 Bug ID: 38598 Summary: Merge r339704 and r339805 to 7.0 branch: critical fixes for OpenMP Product: clang Version: 7.0 Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: a.bat...@hotmail.com CC: llvm-bugs@lists.llvm.org We need to merge r339704 and r339805 to 7.0 branch to fix some critical issues with OpenMP support. -- 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 38299] non-dependent name treated as if it were dependent, requiring use of template keyword
https://bugs.llvm.org/show_bug.cgi?id=38299 Stephen Kelly changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||steve...@gmail.com --- Comment #4 from Stephen Kelly --- I hit exactly this issue too. https://bugs.llvm.org//show_bug.cgi?id=17401 also exists, but it doesn't seem to be an exact duplicate as it does not use inheritance in the repro. *** This bug has been marked as a duplicate of bug 17401 *** -- 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 34182] test_exception_address_alignment fails on ARM
https://bugs.llvm.org/show_bug.cgi?id=34182 Hans Wennborg changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #20 from Hans Wennborg --- And merged to 7.0 in r339881. -- 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 38406] [meta] 7.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=38406 Bug 38406 depends on bug 34182, which changed state. Bug 34182 Summary: test_exception_address_alignment fails on ARM https://bugs.llvm.org/show_bug.cgi?id=34182 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] Issue 8541 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in ExprEvaluatorBase::VisitCallExpr
Updates: Labels: Deadline-Approaching Comment #4 on issue 8541 by sheriff...@chromium.org: llvm/clang-fuzzer: Stack-overflow in ExprEvaluatorBase::VisitCallExpr https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=8541#c4 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 38599] New: wasm32 reduce.fmin/fmax work incorrectly for vectors containing NaNs
https://bugs.llvm.org/show_bug.cgi?id=38599
Bug ID: 38599
Summary: wasm32 reduce.fmin/fmax work incorrectly for vectors containing NaNs
Product: new-bugs
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: gonzalob...@gmail.com
CC: llvm-bugs@lists.llvm.org
This is an attempt at reporting Rust packed_simd/91
(https://github.com/rust-lang-nursery/packed_simd/issues/91).
There we have to functions, min_element and max_element, that work on packed
float vectors. For <4 x float> and min we emit the following LLVM-IR:
define float @min_4x32(<4 x float> %a) {
%b = tail call float @llvm.experimental.reduce.fmin.v4f32(<4 x float> %a)
ret float %b
}
declare float @llvm.experimental.reduce.fmin.v4f32(<4 x float>)
We have a test that initializes the first element of the vector with NaN, and
all other elements with 3.0, and checks that the result is 3.0.
This tests passes on wasm32-unknown-unknown for all f32 and f64 vectors except
for f32x16 (512-bit wide) vectors, where it fails for both the `min` and `max`
operations. Instead of returning `3.0`, this functions return `NaN` (the input
is ` `.
--
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 38600] New: Redefinition errors from double header inclusion on timestamp stale PCH files with -fno-validate-pch
https://bugs.llvm.org/show_bug.cgi?id=38600 Bug ID: 38600 Summary: Redefinition errors from double header inclusion on timestamp stale PCH files with -fno-validate-pch Product: clang Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: ke...@snap.com CC: llvm-bugs@lists.llvm.org Created attachment 20732 --> https://bugs.llvm.org/attachment.cgi?id=20732&action=edit Example App and script to reproduce the bug. Apple LLVM version 9.1.0 (clang-902.0.39.2) -fno-validate-pch will bypass the timestamp validation on precompiled headers, however clang can possibly double include these "stale" headers because of the changed timestamp. This breaks builds systems that rely on content modification instead of timestamp modification (Buck/Bazel). Example project attached. /usr/bin/clang -x objective-c-header header-prefix.h -o header-prefix.h.gch touch lib.h /usr/bin/clang -x objective-c -include-pch header-prefix.h.gch main.m -o main.m.o #This normally fails because of a stale PCH /usr/bin/clang -x objective-c -include-pch header-prefix.h.gch -Wp,-fno-validate-pch main.m -o main.m.o #This bypasses the timestamp check, but somewhere downstream includes the header twice in the example for a redefinition error. -- 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 38601] New: static cast a derived class to base class with defined type case operators
https://bugs.llvm.org/show_bug.cgi?id=38601
Bug ID: 38601
Summary: static cast a derived class to base class with defined
type case operators
Product: new-bugs
Version: trunk
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: luyi0...@gmail.com
CC: llvm-bugs@lists.llvm.org
#include
#include
using Base = std::tuple;
struct Derived : Base {
template
Derived(int x, Ts&&... ts): Base(std::forward(ts)...), x(x) {
}
operator int () const {
return x;
}
int x;
};
int main() {
Derived d(1, 2, 3);
Base b = static_cast(d);
// he output is 0 1 in clang++, but the expected output is 2 3
std::cout << std::get<0>(b) << " " << std::get<1>(b) << std::endl;
return 0;
}
--
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 38602] New: Independent indentation rules for code vs. pre-processor
https://bugs.llvm.org/show_bug.cgi?id=38602 Bug ID: 38602 Summary: Independent indentation rules for code vs. pre-processor Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: cj-l...@zougloub.eu CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org I've seen coding styles which have pre-processor indentation and code indentation using different styles, eg. “indent with single space after hash for pre-processor, vs. indent with tabs, align with spaces for code”. This is not supported by clang-format. -- 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 38603] New: [OpenCL C++] Template parameters are broken due to address space changes
https://bugs.llvm.org/show_bug.cgi?id=38603
Bug ID: 38603
Summary: [OpenCL C++] Template parameters are broken due to
address space changes
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: OpenCL
Assignee: unassignedclangb...@nondot.org
Reporter: erich.ke...@intel.com
CC: llvm-bugs@lists.llvm.org
I haven't been able to run this down, but when parsing a scoped declarator, the
lookup for types don't work:
https://godbolt.org/g/b3JpJb
template
struct integral_constant{
void foo();
};
template
void integral_constant<_Tp>::foo() {}
:7:30: error: nested name specifier 'integral_constant<_Tp>::' for
declaration does not refer into a class, class template or class template
partial specialization
void integral_constant<_Tp>::foo() {}
The address-space changes are somehow messing with canonicalization of the
template parameter itself, thus the lookup for integral_constant<_Tp> doesn't
work correctly.
--
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 38604] New: std::string is too eager in convertibility-to-string_view checks
https://bugs.llvm.org/show_bug.cgi?id=38604 Bug ID: 38604 Summary: std::string is too eager in convertibility-to-string_view checks Product: libc++ Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: ldio...@apple.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Created attachment 20734 --> https://bugs.llvm.org/attachment.cgi?id=20734&action=edit libc++-style test case Since https://reviews.llvm.org/D48616, we’re checking convertibility-to-string_view in several std::string methods. However, those new templated methods are not guarded behind C++17 checks, which means that we’re still making those checks in C++11 and C++14. This is bad for types that provide promiscuous conversion operators, as they can sniff that we're providing these methods in C++11/C++14. This breaks conforming (but misbehaved) code. I attached a test case that currently fails. -- 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 38605] New: Linker segfault while compiling `libc++abi` (in tests)
https://bugs.llvm.org/show_bug.cgi?id=38605 Bug ID: 38605 Summary: Linker segfault while compiling `libc++abi` (in tests) Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: psychox...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, I explained bug here as far as I can: https://github.com/llvm-project/llvm-project-20170507/issues/7 So here I maybe just paste the post from GitHub issues: ``` I am trying to compile libc++abi for x86_64-w64-mingw32 target. I am using newest SVN version of the libraries (svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi -> revision 339892) There I posted whole build command (BuildCommand.sh), console output (ConsoleOutput.log) and CMake logs (CMakeOutput.log,CMakeError.log`): https://gist.github.com/PsychoXIVI/c9323c0ab169fb0ed475b112a2f62737 While reading CMakeError I noticed Segmentation fault (core dumped) for lld linker, so here I am since I even don't know what to do next... ``` -- 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 38606] New: Bit-wise rather than logical ‘and’ for decremented size_type in __hash_table gives unsigned integer overflow warning
https://bugs.llvm.org/show_bug.cgi?id=38606 Bug ID: 38606 Summary: Bit-wise rather than logical ‘and’ for decremented size_type in __hash_table gives unsigned integer overflow warning Product: libc++ Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: fl...@pobox.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com The Undefined Behavior Sanitizer with unsigned-integer-overflow enabled complains about the following code in https://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__hash_table: 2251__hash_table<_Tp, _Hash, _Equal, _Alloc>::rehash(size_type __n) … 2255else if (__n & (__n - 1)) The bit-wise rather than logical ‘and’, to produce a Boolean, on an unsigned value which is being decremented, strikes me as poor style if not simply a mistake. It also prevents short-circiting, which might mitigate any performance hit to correcting this. This is of course not actually undefined behavior, since decrementing an unsigned zero is defined to be a large positive value. But I’ve seen dozens of incorrect unsigned decrementing bugs detected by static analysis, and never a serious need to use unsigneds as elements of modular arithmetic rather than as a risky approximation to genuine integers. So this sanitizer option strikes me as worthwhile, but silencing the warning for this usage was fairly inconvenient for our build system. This would not have inconvenienced us if PR 25706 had been implemented, but it seems not to have been, despite the resolution. -- 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 38288] clang miscompiles with "-newgvn" at -O3 in 32-bit mode on valid code
https://bugs.llvm.org/show_bug.cgi?id=38288 Qirun Zhang changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED --- Comment #2 from Qirun Zhang --- Florian, would you please double check? It still happens on my linux machine. I can also confirm it on a mac machine with clang-r339912. $ clang-trunk -v clang version 8.0.0 (trunk 339849) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin $ clang-trunk -mllvm -enable-newgvn -m32 -O3 a.c ; ./a.out 0 -- 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 38607] New: Using a private global as a global_ctor key fails when emitting a COFF object
https://bugs.llvm.org/show_bug.cgi?id=38607
Bug ID: 38607
Summary: Using a private global as a global_ctor key fails when
emitting a COFF object
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: david.majne...@gmail.com, llvm-bugs@lists.llvm.org
Consider this LLVM IR:
@x = private global i32 0
@llvm.global_ctors = appending global [1 x { i32, void ()*, i8* }]
[{ i32, void ()*, i8* }
{ i32 65535,
void ()* @register_x,
i8* bitcast (i32* @x to i8*) }]
define internal void @register_x() {
ret void
}
We can generate asm for it, but we cannot assemble it to an object. We emit:
$ llc t.ll -o t.o -filetype=obj
LLVM ERROR: Missing associated COMDAT section for section .CRT$XCU
Mechanically, what happens is we try to look up a private label (.Lx) in the
COFF symbol table that we're making, we use GetOrCreate on it, but we don't
have a section for it, so we issue this diagnostic.
However, the input LLVM IR makes some sense. We should run the initializer if
and only if @x is included in the final link, and it's not comdat, so it will
be included, and we can just ignore it and always put @register_x in the main
.CRT$XCU section.
The question is, should we accept the assembly that we generate today?
.section.rdata,"dr"
.p2align2 # @x
.Lx:
.long 0 # 0x0
.section.CRT$XCU,"dr",associative,.Lx
.p2align3
.quad register_x
Does that assembly make sense, i.e. make this .CRT$XCU section associative with
the non-comdat .rdata section?
--
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 38607] Using a private global as a global_ctor key fails when emitting a COFF object
https://bugs.llvm.org/show_bug.cgi?id=38607 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Reid Kleckner --- I went ahead and did this in r339942. Let me know if you think it's wrong. -- 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 38607] Using a private global as a global_ctor key fails when emitting a COFF object
https://bugs.llvm.org/show_bug.cgi?id=38607 Reid Kleckner changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #3 from Reid Kleckner --- That's reasonable, but I don't think we should check it in the assembler, I think that would be the responsibility of codegen. I think it's better if MC is "dumb" and lets the user make weird object files to make it easier to test linker corner cases. -- 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 9935 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: BitPosition <= BitWidth && "BitPosition out of range"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer Proj-llvm Reported-2018-08-16 Type: Bug New issue 9935 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: BitPosition <= BitWidth && "BitPosition out of range" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9935 Detailed report: https://oss-fuzz.com/testcase?key=5710919983169536 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: BitPosition <= BitWidth && "BitPosition out of range" extractShiftForRotate DAGCombiner::MatchRotate Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201807300245:201807310248 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5710919983169536 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 38608] New: Fragment variable size verification fails during LTO in presence of ODR violations
https://bugs.llvm.org/show_bug.cgi?id=38608
Bug ID: 38608
Summary: Fragment variable size verification fails during LTO
in presence of ODR violations
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: r...@google.com
CC: bjorn.a.petters...@ericsson.com,
llvm-bugs@lists.llvm.org, l...@inglorion.net,
pe...@pcc.me.uk
Our Chromium ThinLTO bot has been red longer than we have history for it, and I
think it was caused by r334830 from June.
During LTO, our bot is now producing this error:
fragment is larger than or outside of variable
call void @llvm.dbg.value(metadata i8 %9, metadata !2265359, metadata
!DIExpression(DW_OP_LLVM_fragment, 96, 8)), !dbg !2265363
!2265359 = !DILocalVariable(name: "p", scope: !2265356, f
Here is a reduction of the problem:
// a.cpp
struct ViolateODR {
int x;
};
int use_small_struct(ViolateODR o) {
return o.x;
}
int do_sroa(int x, int y);
int main() {
ViolateODR o = {0};
return use_small_struct(o) + do_sroa(1, 2);
}
// b.cpp
struct ViolateODR {
int x;
};
int use_small_struct(ViolateODR o) {
return o.x;
}
int do_sroa(int x, int y);
int main() {
ViolateODR o = {0};
return use_small_struct(o) + do_sroa(1, 2);
}
// script
$ clang-cl -Z7 -flto=thin -c a.cpp b.cpp -O2 && lld-link a.obj b.obj -out:t.exe
fragment covers entire variable
call void @llvm.dbg.value(metadata i32 %3, metadata !17, metadata
!DIExpression(DW_OP_LLVM_fragment, 0, 32)), !dbg !24
!17 = !DILocalVariable(name: "o", scope: !10, file: !1, line: 6, type: !18)
OK, so maybe I got a.cpp and b.cpp swapped, but you see the point. I don't
think verifier errors during LTO are a reasonable failure mode for ODR
violations.
I would prefer it if instead dbg.value problems could be reported as warnings
and we could locally discard the problematic dbg.value instructions.
--
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 38125] clang miscompiles at -O2 and above on valid code
https://bugs.llvm.org/show_bug.cgi?id=38125 Carrot changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Carrot --- Fixed by r339822. -- 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 38609] New: [codeview] Clang needs to generate unique mangled names for types in anonymous namespaces
https://bugs.llvm.org/show_bug.cgi?id=38609 Bug ID: 38609 Summary: [codeview] Clang needs to generate unique mangled names for types in anonymous namespaces Product: clang Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: r...@google.com CC: brock.w...@intel.com, llvm-bugs@lists.llvm.org, l...@inglorion.net In CodeView, most struct types are referred to through forward declarations that use the mangled name of the type. If the type's mangled name is not unique across the whole project, the debugger will find the wrong one. This issue was discussed as part of https://reviews.llvm.org/D45438, but so far as I can tell nobody filed a bug for this. This hasn't been a huge problem so far, but perhaps it's just because we don't have enough debugger power users to report the issue. However, when type names collide, debug info verification during ThinLTO now fails. I reported that as https://bugs.llvm.org/show_bug.cgi?id=38608. In order to avoid these problems, Clang needs to hash some kind of deterministic module identifier into the way it mangles names in anonymous namespaces. One reasonable thing to do would be to hash the compiler invocation, or whatever parts are conveniently hashable, such as just the path to the main source file. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38610] New: ThinLTO doesn't use all virtual cores as advertised
https://bugs.llvm.org/show_bug.cgi?id=38610 Bug ID: 38610 Summary: ThinLTO doesn't use all virtual cores as advertised Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mh+l...@glandium.org CC: llvm-bugs@lists.llvm.org The ThinLTO documentation (https://clang.llvm.org/docs/ThinLTO.html) says: By default, the ThinLTO link step will launch up to std::thread::hardware_concurrency number of threads in parallel. For machines with hyper-threading, this is the total number of virtual cores. That appears not to be true. On a machine with 8 cores and 16 hyper-threads, std::thread::hardware_concurrency returns 16, but the linkage (with lld) only uses 8 threads. I have to manually pass --thinlto-jobs=16 for 16 threads to be used. This does make a difference, where the linkage with 16 threads takes 75% of the time the one with 8 threads takes. Tangentially, GCC has (opt-in) Make jobserver support, which is even 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] [Bug 38577] XRay Profiling: Remove dependency on InternalAlloc/InternalFree
https://bugs.llvm.org/show_bug.cgi?id=38577 Dean Michael Berris changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Dean Michael Berris --- Fixed in r339978. -- 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 38611] New: False positive
https://bugs.llvm.org/show_bug.cgi?id=38611
Bug ID: 38611
Summary: False positive
Product: clang
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: m...@sunchangming.com
CC: llvm-bugs@lists.llvm.org
Test code:
```
#include
#include
#include
class Status {
public:
~Status(){delete state_;}
bool IsOK() const {
return (state_ == 0);
}
static Status OK() {
return Status();
}
private:
const std::string* state_ = 0;
};
Status Convert(int ** out) {
*out = new int;
**out = 1;
return Status::OK();
}
int main(int argc,char* argv[]){
int* tensor = 0;
const Status st = Convert(&tensor);
if (!st.IsOK()) return -1;
delete tensor;
return 0;
}
```
Output:
/usr/libexec/c++-analyzer-Wall -Wextra -o main.o -c
/data/clang_test/main.cpp
/data/clang_test/main.cpp: In function ‘int main(int, char**)’:
/data/clang_test/main.cpp:27:14: warning: unused parameter ‘argc’
[-Wunused-parameter]
int main(int argc,char* argv[]){
^~~~
/data/clang_test/main.cpp:27:25: warning: unused parameter ‘argv’
[-Wunused-parameter]
int main(int argc,char* argv[]){
~~^~
/data/clang_test/main.cpp:30:27: warning: Potential leak of memory pointed to
by 'tensor'
if (!st.IsOK()) return -1;
^
1 warning generated.
However, if I remove the destructor, everything is fine.
--
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 38612] New: Openmp failed to build with LIBOMP_USE_DEBUGGER=ON
https://bugs.llvm.org/show_bug.cgi?id=38612 Bug ID: 38612 Summary: Openmp failed to build with LIBOMP_USE_DEBUGGER=ON Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: cha...@microsoft.com CC: llvm-bugs@lists.llvm.org In kmp_debugger.cpp, Should insert a line of #include "kmp_config.h" before #if USE_DEBUGGER Otherwise, USE_DEBUGGER is always undefined. -- 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 38611] False positive
https://bugs.llvm.org/show_bug.cgi?id=38611 Changming Sun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Changming Sun --- After switching to clang 7.0rc1 and enable z3, the FP is gone. Therefore, I don't think it need be 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
