[llvm-bugs] Issue 5787 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: N2.getValueSizeInBits() >= Log2_32_Ceil(N1.getValueSizeInBits()) && "Invalid use
Comment #2 on issue 5787 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: N2.getValueSizeInBits() >= Log2_32_Ceil(N1.getValueSizeInBits()) && "Invalid use https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5787#c2 ClusterFuzz has detected this issue as fixed in range 201802200626:201802210603. Detailed report: https://oss-fuzz.com/testcase?key=4817034052370432 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: N2.getValueSizeInBits() >= Log2_32_Ceil(N1.getValueSizeInBits()) && "Invalid use llvm::SelectionDAG::getNode llvm::TargetLowering::SimplifySetCC Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201802200626:201802210603 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4817034052370432 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 5787 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: N2.getValueSizeInBits() >= Log2_32_Ceil(N1.getValueSizeInBits()) && "Invalid use
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 5787 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: ASSERT: N2.getValueSizeInBits() >= Log2_32_Ceil(N1.getValueSizeInBits()) && "Invalid use https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5787#c3 ClusterFuzz testcase 4817034052370432 is verified as fixed, so closing issue as verified. 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 36091] [X86][SSE] Failure to vectorize load+extend v8i8 to v8i16
https://bugs.llvm.org/show_bug.cgi?id=36091 Dinar Temirbulatov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dinar Temirbulatov --- Fixed after rL324893. -- 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 36465] New: Support 128-bit integers.
https://bugs.llvm.org/show_bug.cgi?id=36465 Bug ID: 36465 Summary: Support 128-bit integers. Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: CUDA Assignee: unassignedclangb...@nondot.org Reporter: gonzalob...@gmail.com CC: llvm-bugs@lists.llvm.org Currently the cuda backend does not support 128-bit integers in cuda kernels. It would be a great improvement over nvcc to support these by emulating them as two 64 bit integers. -- 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 36462, which changed state. Bug 36462 Summary: Merge r325654 and r325655 into 6.0 branch: [X86] Disable CLWB on Cannon Lake https://bugs.llvm.org/show_bug.cgi?id=36462 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 36462] Merge r325654 and r325655 into 6.0 branch: [X86] Disable CLWB on Cannon Lake
https://bugs.llvm.org/show_bug.cgi?id=36462 Hans Wennborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||h...@chromium.org --- Comment #1 from Hans Wennborg --- Merged in r325671 and r325672, respectively. -- 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 36466] New: Assertion `I != M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed
https://bugs.llvm.org/show_bug.cgi?id=36466
Bug ID: 36466
Summary: Assertion `I != M+Size && I->FromReg == RegNum &&
"Invalid RegNum"' failed
Product: tools
Version: 6.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: llvm-dwarfdump
Assignee: unassignedb...@nondot.org
Reporter: danti...@nvidia.com
CC: llvm-bugs@lists.llvm.org
The following llvm-dwarfdump assertion failure may be caused by dumping
Firefox's core library libxul.so:
llvm-dwarfdump: /home/dantipov/llvm/6.0.0/source/lib/MC/MCRegisterInfo.cpp:87:
int llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool) const: Assertion `I
!= M+Size && I->FromReg == RegNum && "Invalid RegNum"' failed.
#0 0x00758b08 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
/home/dantipov/llvm/6.0.0/source/lib/Support/Unix/Signals.inc:398:0
#1 0x00758b9b PrintStackTraceSignalHandler(void*)
/home/dantipov/llvm/6.0.0/source/lib/Support/Unix/Signals.inc:462:0
#2 0x00757040 llvm::sys::RunSignalHandlers()
/home/dantipov/llvm/6.0.0/source/lib/Support/Signals.cpp:49:0
#3 0x0075847d SignalHandler(int)
/home/dantipov/llvm/6.0.0/source/lib/Support/Unix/Signals.inc:252:0
#4 0x7f3a7ce17af0 __restore_rt (/lib64/libpthread.so.0+0x12af0)
#5 0x7f3a7b91766b __GI_raise
/usr/src/debug/glibc-2.26-137-g247c1ddd30/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#6 0x7f3a7b919381 __GI_abort
/usr/src/debug/glibc-2.26-137-g247c1ddd30/stdlib/abort.c:81:0
#7 0x7f3a7b90f8fa __assert_fail_base
/usr/src/debug/glibc-2.26-137-g247c1ddd30/assert/assert.c:89:0
#8 0x7f3a7b90f972 (/lib64/libc.so.6+0x2f972)
#9 0x00597124 llvm::MCRegisterInfo::getLLVMRegNum(unsigned int, bool)
const /home/dantipov/llvm/6.0.0/source/lib/MC/MCRegisterInfo.cpp:88:0
#10 0x00484a44 llvm::prettyPrintRegisterOp(llvm::raw_ostream&, unsigned
char, unsigned long*, llvm::MCRegisterInfo const*, bool)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFExpression.cpp:206:0
#11 0x00484c4a
llvm::DWARFExpression::Operation::print(llvm::raw_ostream&,
llvm::DWARFExpression const*, llvm::MCRegisterInfo const*, bool)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFExpression.cpp:237:0
#12 0x00484e81 llvm::DWARFExpression::print(llvm::raw_ostream&,
llvm::MCRegisterInfo const*)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFExpression.cpp:263:0
#13 0x0047590c dumpExpression(llvm::raw_ostream&, llvm::ArrayRef,
bool, unsigned int, llvm::MCRegisterInfo const*)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp:37:0
#14 0x00475a8d
llvm::DWARFDebugLoc::LocationList::dump(llvm::raw_ostream&, bool, unsigned int,
llvm::MCRegisterInfo const*, unsigned int) const
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFDebugLoc.cpp:43:0
#15 0x0047de28 dumpLocation(llvm::raw_ostream&, llvm::DWARFFormValue&,
llvm::DWARFUnit*, unsigned int, llvm::DIDumpOptions)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFDie.cpp:113:0
#16 0x0047eb32 dumpAttribute(llvm::raw_ostream&, llvm::DWARFDie const&,
unsigned int*, llvm::dwarf::Attribute, llvm::dwarf::Form, unsigned int,
llvm::DIDumpOptions)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFDie.cpp:250:0
#17 0x0048024b llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int,
llvm::DIDumpOptions) const
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFDie.cpp:489:0
#18 0x0048030a llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int,
llvm::DIDumpOptions) const
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFDie.cpp:498:0
#19 0x0048030a llvm::DWARFDie::dump(llvm::raw_ostream&, unsigned int,
llvm::DIDumpOptions) const
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFDie.cpp:498:0
#20 0x004298c2 llvm::DWARFCompileUnit::dump(llvm::raw_ostream&,
llvm::DIDumpOptions)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFCompileUnit.cpp:33:0
#21 0x0042b52f operator()
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFContext.cpp:311:0
#22 0x0042b52f llvm::DWARFContext::dump(llvm::raw_ostream&,
llvm::DIDumpOptions, std::array,
23ul>)::{lambda(bool, char const*, llvm::DWARFSection,
llvm::iterator_range >*>)#2}::operator()(bool, char
const*, llvm::DWARFSection,
llvm::iterator_range >*>) const
(/home/dantipov/.local/llvm-6.0.0/bin/llvm-dwarfdump+0x42b52f)
#23 0x0042bc8b llvm::DWARFContext::dump(llvm::raw_ostream&,
llvm::DIDumpOptions, std::array, 23ul>)
/home/dantipov/llvm/6.0.0/source/lib/DebugInfo/DWARF/DWARFContext.cpp:315:0
#24 0x0040d8fe dumpObjectFile(llvm::object::ObjectFile&,
llvm::DWARFContext&, llvm::Twine, llvm::raw_ostream&)
/home/dantipov/llvm/6.0.0/source/tools/llvm-dwarfdump/llvm-dwarfdump.cpp:389:0
#25 0x0041dbdf std::_Function_handler:
[llvm-bugs] Issue 4142 in oss-fuzz: llvm/clangd-fuzzer: Timeout in llvm_clangd-fuzzer
Updates: Status: WontFix Comment #7 on issue 4142 by ClusterFuzz-External: llvm/clangd-fuzzer: Timeout in llvm_clangd-fuzzer https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4142#c7 ClusterFuzz testcase 4598102297149440 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 4759 in oss-fuzz: llvm: Stack-overflow in PointerExprEvaluator::VisitBinaryOperator
Updates: Status: WontFix Comment #4 on issue 4759 by ClusterFuzz-External: llvm: Stack-overflow in PointerExprEvaluator::VisitBinaryOperator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4759#c4 ClusterFuzz testcase 5112779787730944 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 5009 in oss-fuzz: llvm: Stack-overflow in clang::DeclContext::lookup
Updates: Status: WontFix Comment #3 on issue 5009 by ClusterFuzz-External: llvm: Stack-overflow in clang::DeclContext::lookup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5009#c3 ClusterFuzz testcase 5690793223258112 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 28234] [mc] buffer_load -- lds attribute is not supported.
https://bugs.llvm.org/show_bug.cgi?id=28234 Dmitry changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Dmitry --- Closed by commit rL325676 http://llvm.org/viewvc/llvm-project?rev=325676&view=rev -- 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|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Hans Wennborg --- Turns out this is just gold and OpenBSD's ld spelling the option differently. I've added an alias in r325679 and merged that to 6.0 in r325680. Brad, please re-open if there are still issues. -- 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 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|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 36467] New: Compiling Exim mailserver with clang and gold linker(-flto) the created archive files (.a) are invalid.
https://bugs.llvm.org/show_bug.cgi?id=36467 Bug ID: 36467 Summary: Compiling Exim mailserver with clang and gold linker(-flto) the created archive files (.a) are invalid. Product: new-bugs Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: sami.djaf...@gmail.com CC: llvm-bugs@lists.llvm.org compiling Exim with setting CC=clang-5.0 -flto creates the object files as LLVM IR Bitcode, and also the archive file that has a collection of these objects become invalid. --the NM output: nm: auth-spa.o: File format not recognized nm: call_pam.o: File format not recognized nm: call_pwcheck.o: File format not recognized nm: call_radius.o: File format not recognized nm: check_serv_cond.o: File format not recognized nm: cram_md5.o: File format not recognized nm: cyrus_sasl.o: File format not recognized nm: dovecot.o: File format not recognized nm: get_data.o: File format not recognized nm: get_no64_data.o: File format not recognized nm: gsasl_exim.o: File format not recognized nm: heimdal_gssapi.o: File format not recognized nm: md5.o: File format not recognized nm: plaintext.o: File format not recognized nm: pwcheck.o: File format not recognized nm: spa.o: File format not recognized nm: tls.o: File format not recognized nm: xtextdecode.o: File format not recognized nm: xtextencode.o: File format not recognized --The error on console is as follow: clang-5.0 -flto -o exim_fixdb auths/auths.a: error adding symbols: Archive has no index; run ranlib to add one clang: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:641: recipe for target 'exim_fixdb' failed make[1]: *** [exim_fixdb] Error 1 make[1]: Leaving directory '/home/saman/exim/exim-clang5_2/exim/src/build-Linux-x86_64' Makefile:35: recipe for target 'all' failed make: *** [all] Error 2 -- 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 36468] New: [Formatter/ObjC] Add // clang-format Language=XXX support
https://bugs.llvm.org/show_bug.cgi?id=36468 Bug ID: 36468 Summary: [Formatter/ObjC] Add // clang-format Language=XXX support Product: clang Version: trunk Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: bhamilto...@gmail.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org The heuristic to guess ObjC vs C++ is pretty good now, but there will always be cases where it fails, e.g. === #import "SomeOtherHeader.h" int DoStuff(SomeOtherType *type); === where we cannot tell from the lexer if this is C++ or ObjC. To fix this, we should add support for a special comment, similar to the existing "clang-format off" comment. Something like this: === #import "SomeOtherHeader.h" // clang-format Language=ObjC int DoStuff(SomeOtherType *type); === -- 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 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|RESOLVED|REOPENED 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 Rui Ueyama changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from Rui Ueyama --- Apologies, I didn't notice this bug before. But I think I have to revert that change because I'm not convinced that that's a bug. Actually in the thread, most people seems to be in agreement that lld shouldn't accept -nopie. Brad, you said that just "No" when I asked if you could change OpenBSD instead of lld. But just saying no isn't enough to convince us to make lld compatible with OpenBSD-local extensions for the obvious reason. Please join to the discussion thread again if you still think that lld should accept "-nopie". -- 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] New: 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
Bug ID: 36469
Summary: std::invoke of std::optional::has_value
pointer-to-member-function fails, due to its class
type being a private base.
Product: libc++
Version: 4.0
Hardware: All
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: ari...@stack.nl
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The following code snippet:
#include
#include
bool testfn(std::optional opt_int) {
return std::invoke(&std::optional::has_value, opt_int);
}
Compiler output (c++ -std=c++1z -c -o test.o test.cc):
test.cc:5:10: error: no matching function for call to 'invoke'
return std::invoke(&std::optional::has_value, opt_int);
^~~
/usr/include/c++/v1/functional:2589:1: note: candidate template ignored:
substitution failure [with _Fn = bool
(std::__1::__optional_storage_base::*)() const noexcept,
_Args = &>]: no type named 'type' in
'std::__1::result_of::*&&(std::__1::optional &))() const noexcept>'
invoke(_Fn&& __f, _Args&&... __args)
^
1 error generated.
(I have a hard time reading the error message, but it looks to me like
std::result_of template argument is a zero-argument function that returns a
function.)
Compiler version:
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM
4.0.0)
Target: x86_64-unknown-freebsd11.1
Thread model: posix
InstalledDir: /usr/bin
Additionally, the following snippet does not compile, while to me seems valid:
std::optional opt_int;
auto fn_ptr = &std::optional::has_value;
bool manual_invocation = (opt_int.*fn_ptr)();
--
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 36470] New: clang/llvm revision 325569 and newer are unable to build Firefox, with "test-ctors.so: terminate called after throwing an instance of 'std::runtime_error'" and then " what
https://bugs.llvm.org/show_bug.cgi?id=36470 Bug ID: 36470 Summary: clang/llvm revision 325569 and newer are unable to build Firefox, with "test-ctors.so: terminate called after throwing an instance of 'std::runtime_error'" and then " what(): Unsupported relocation type" Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: dholb...@mozilla.com CC: gri...@accesssoftek.com, llvm-bugs@lists.llvm.org, mh+l...@glandium.org, sylves...@debian.org I build Firefox with clang trunk (which I build locally ~weekly), and I noticed today that I got a build failure with the newest clang trunk. Specifically: llvm revision 325568 builds Firefox fine llvm revision 325569 hits a build error So I believe this is a regression from grimar's https://reviews.llvm.org/D43383 The build error is in the "elfhack" stage of the build, and my output looks like this: 4:21.16 === If you get failures below, please file a bug describing the error 4:21.16 === and your environment (compiler and linker versions), and 4:21.16 === provide the pre-elfhacked library as an attachment. 4:21.16 === Use --disable-elf-hack until this is fixed. 4:21.16 === 4:21.17 0x000c (INIT) 0x4060 4:21.17 test-ctors.so: terminate called after throwing an instance of 'std::runtime_error' 4:21.17 what(): Unsupported relocation type 4:21.22 Makefile:17: recipe for target 'test-array.so' failed 4:21.22 make[4]: *** [test-array.so] Aborted (core dumped) 4:21.22 make[4]: *** Waiting for unfinished jobs 4:21.28 Makefile:17: recipe for target 'test-ctors.so' failed 4:21.28 make[4]: *** [test-ctors.so] Aborted (core dumped) 4:21.28 /scratch/work/builds/mozilla-inbound/mozilla/config/recurse.mk:100: recipe for target 'build/unix/elfhack/libs' failed 4:21.28 make[3]: *** [build/unix/elfhack/libs] Error 2 4:21.28 /scratch/work/builds/mozilla-inbound/mozilla/config/recurse.mk:32: recipe for target 'libs' failed 4:21.28 make[2]: *** [libs] Error 2 4:21.28 /scratch/work/builds/mozilla-inbound/mozilla/config/rules.mk:434: recipe for target 'default' failed 4:21.28 make[1]: *** [default] Error 2 4:21.28 client.mk:168: recipe for target 'build' failed 4:21.28 make: *** [build] Error 2 The "Aborted (core dumped)" there looks like it's saying the compiler crashed, I think -- 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 36470] clang/llvm revision 325569 and newer are unable to build Firefox, with "test-ctors.so: terminate called after throwing an instance of 'std::runtime_error'" and then " what(): U
https://bugs.llvm.org/show_bug.cgi?id=36470 Mike Hommey changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Mike Hommey --- elfhack is effectively a linker, and supports very few relocation types. As you pointed out in the Firefox bug, revision 325569 changed a relocation type emitted by LLVM, and while elfhack has support for R_X86_64_PC32, it lacks support for R_X86_64_PLT32. IOW, not a LLVM bug. -- 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 23000] Immediates that need shifts are misassembled for ARM
https://bugs.llvm.org/show_bug.cgi?id=23000 Renato Golin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Renato Golin --- Marking this as resolved, since it was fixed months 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 20422] [Meta] Chromium building with -integrated-as on ARM
https://bugs.llvm.org/show_bug.cgi?id=20422 Bug 20422 depends on bug 23000, which changed state. Bug 23000 Summary: Immediates that need shifts are misassembled for ARM https://bugs.llvm.org/show_bug.cgi?id=23000 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 36471] New: lld should give a verbose warning or error on /debug:fastlink
https://bugs.llvm.org/show_bug.cgi?id=36471 Bug ID: 36471 Summary: lld should give a verbose warning or error on /debug:fastlink Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: brucedaw...@chromium.org CC: llvm-bugs@lists.llvm.org LLD doesn't support /debug:fastlink but when it is selected it is accepted (confusing) and gives different results from /debug (also confusing). If lld printed an error message when /debug:fastlink was specified then this would avoid this confusion quite easily. -- 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 36472] New: clang frontend command failed due to signal
https://bugs.llvm.org/show_bug.cgi?id=36472 Bug ID: 36472 Summary: clang frontend command failed due to signal Product: clang Version: 5.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: s...@list.ru CC: llvm-bugs@lists.llvm.org Created attachment 19924 --> https://bugs.llvm.org/attachment.cgi?id=19924&action=edit test-case The attached test-case produces the compiler crash. $ clang++ -std=c++11 -c malloca.cpp clang-5.0: error: unable to execute command: Segmentation fault (core dumped) clang-5.0: error: clang frontend command failed due to signal (use -v to see invocation) This code is actually a result of the question I asked here: https://stackoverflow.com/questions/48915888/allocate-shared-with-malloc Maybe someone from clang devs/C++ gurus can hint me about why do I need to manually override the delete operator 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
