[llvm-bugs] [Bug 33809] [clang-format/C++] version 5.0.0 (trunk?) adds empty line after 'public:' where previous versions don't
https://bugs.llvm.org/show_bug.cgi?id=33809 Daniel Jasper changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #1 from Daniel Jasper --- This was an intended behavior change. -- 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 33813] New: Optimization for removing same variable comparisons in loop: while(it != end1 && it != end2)
https://bugs.llvm.org/show_bug.cgi?id=33813
Bug ID: 33813
Summary: Optimization for removing same variable comparisons in
loop: while(it != end1 && it != end2)
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: antosh...@gmail.com
CC: llvm-bugs@lists.llvm.org
Simple iteration by std::deque elements produces suboptimal code. For example
#include
unsigned sum(std::deque cont) {
unsigned sum = 0;
for (unsigned v : cont)
sum += v;
return sum;
}
produces the following loop:
.LBB0_1:# =>This Inner Loop Header: Depth=1
cmp rsi, rcx
je .LBB0_4
add eax, dword ptr [rcx]
add rcx, 4
cmp rcx, rdx
jne .LBB0_1
jmp .LBB0_3
The loop has two comparisons in it and behaves close to the following C code:
unsigned sum_like_deque_does(unsigned** chunks, unsigned* end) {
unsigned sum = 0;
for (unsigned* it = *chunks; it != end; it = *(++chunks)) {
for (;it != end && it != *chunks + 128; ++it) {
sum += *it;
}
}
return sum;
}
Note the `it != end && it != *chunks + 128` condition. It could be simplified:
if `end` belongs to `[it, *chunks + 128]` change the condition to `it != end`
and use the condition `it != *chunks + 128` otherwise. Such optimization
removes the cmp from the loop and produces a much more faster loop:
.LBB2_3:# Parent Loop BB2_2 Depth=1
add eax, dword ptr [rcx]
add rcx, 4
cmp rdx, rcx
jne .LBB2_3
Synthetic tests show up to 2 times better performance. Assembly outputs:
https://godbolt.org/g/vGs2qs
--
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 33814] New: if (!@available) doesn't work and has confusing diagnostic
https://bugs.llvm.org/show_bug.cgi?id=33814
Bug ID: 33814
Summary: if (!@available) doesn't work and has confusing
diagnostic
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org
We're using @available some in chrome, and I'm getting feedback that people are
confused about writing `if (!@available`. That's kind of understandable, here's
the current experience:
thakis@thakis:~/src/chrome/src$ cat test.mm
void f() {
if (!@available(macos 10.10, *)) {
return;
}
// 10.10-only code here
}
thakis@thakis:~/src/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang -c test.mm -target
x86_64-apple-darwin
test.mm:2:8: warning: @available does not guard availability here; use if
(@available) instead [-Wunsupported-availability-guard]
if (!@available(macos 10.10, *)) {
^
It'd be cool if this pattern just worked somehow (full CFG-awareness likely
isn't needed).
Even just `if (!@available()) {} else {}` so that the else block gets the
available OS would be nice.
If that isn't feasible, making the error message more explicit might help.
(But maybe just having the docs is good enough too, most people who are
confused about this haven't read the docs we added on Friday yet.)
--
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 33815] New: Idea: Extend @available so that it can imply an upper bound too
https://bugs.llvm.org/show_bug.cgi?id=33815
Bug ID: 33815
Summary: Idea: Extend @available so that it can imply an upper
bound too
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@lists.llvm.org
(Feature idea; not important; feel free to WontFix.)
This is a somewhat common pattern:
if (@available(macos 10.10, *)) {
DoThingUsingNewAPIs()
} else {
DoThingUsingOldAPIs()
}
(e.g. here:
https://cs.chromium.org/chromium/src/content/common/quarantine/quarantine_mac.mm?l=239)
@available helps with the first half of that branch, but the implementation of
DoThingUsingOldAPIs() often has to suppress Wdeprecated-declaration (see e.g.
the above-linked file). It'd be cool if the else of an if
(@available(macos10.10)) was a "at most macOS 10.9" region, which could call
functions marked with attrib(availability(deprecated=10.10), and then in those
functions calls to deprecated functions wouldn't be emitted.
...hmm, looking more at this example, there's this comment:
// Once Chrome no longer supports macOS 10.9, this code will no longer be
// necessary. Note that LSCopyItemAttribute was deprecated in macOS 10.8, but
// the replacement to kLSItemQuarantineProperties did not exist until macOS
// 10.10.
So I think this only helps in situations where the availability annotation in
the SDK is wrong. Suppressing warnings for that is OK, I suppose.
--
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 33815] Idea: Extend @available so that it can imply an upper bound too
https://bugs.llvm.org/show_bug.cgi?id=33815 Nico Weber changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 33816] New: @available feature request: Make * not mandatory
https://bugs.llvm.org/show_bug.cgi?id=33816 Bug ID: 33816 Summary: @available feature request: Make * not mandatory Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Frontend Assignee: unassignedclangb...@nondot.org Reporter: nicolaswe...@gmx.de CC: llvm-bugs@lists.llvm.org We currently have functions IsAtLeastOS10_10() (IsAtLeastOS10_11(), etc). These return if the current OS is macOS, and it has at least a certain version. We could almost replace them with @available(), except that that means "os is at least macOS version N, or a different OS" (due to the `*`). If @available's * wasn't mandatory and if omitting it would mean "os matches one of the listed OSs, but nothing else", we could use that instead. Have you considered making the * not mandatory? -- 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 33817] New: Fails to build on gcc 5.4.0 and libstdc++ 6 because bind is missing in TaskPool.h
https://bugs.llvm.org/show_bug.cgi?id=33817 Bug ID: 33817 Summary: Fails to build on gcc 5.4.0 and libstdc++ 6 because bind is missing in TaskPool.h Product: lldb Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: joshker...@gmail.com CC: llvm-bugs@lists.llvm.org Created attachment 18805 --> https://bugs.llvm.org/attachment.cgi?id=18805&action=edit Fixed header file Error is return by ninja on gcc 5.4.0 on ArchLinux when linking against libstdc++. I attached the fix that allowed me to build lldb on my computer. I just added to TaskPool.h FAILED: tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/TaskPool.cpp.o /usr/bin/c++ -DGTEST_HAS_RTTI=0 -DHAVE_PROCESS_VM_READV -DHAVE_ROUND -DLIBXML2_DEFINED -DLLDB_USE_BUILTIN_DEMANGLER -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lldb/source/Utility -I/home/jkergan/Development/llvm/tools/lldb/source/Utility -I/home/jkergan/Development/llvm/tools/lldb/include -Itools/lldb/include -Iinclude -I/home/jkergan/Development/llvm/include -I/usr/include/python2.7 -I/home/jkergan/Development/llvm/tools/clang/include -Itools/lldb/../clang/include -I/usr/include/libxml2 -I/home/jkergan/Development/llvm/tools/lldb/source/. -I/home/jkergan/Development/llvm/tools/lldb/source/Plugins/Process/Linux -I/home/jkergan/Development/llvm/tools/lldb/source/Plugins/Process/POSIX -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -g -fno-exceptions -fno-rtti -MD -MT tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/TaskPool.cpp.o -MF tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/TaskPool.cpp.o.d -o tools/lldb/source/Utility/CMakeFiles/lldbUtility.dir/TaskPool.cpp.o -c /home/jkergan/Development/llvm/tools/lldb/source/Utility/TaskPool.cpp In file included from /home/jkergan/Development/llvm/tools/lldb/source/Utility/TaskPool.cpp:10:0: /home/jkergan/Development/llvm/tools/lldb/include/lldb/Utility/TaskPool.h: In static member function ‘static std::future::type> TaskPool::AddTask(F&&, Args&& ...)’: /home/jkergan/Development/llvm/tools/lldb/include/lldb/Utility/TaskPool.h:122:12: error: ‘bind’ is not a member of ‘std’ std::bind(std::forward(f), std::forward(args)...)); ^~~~ /home/jkergan/Development/llvm/tools/lldb/include/lldb/Utility/TaskPool.h:122:12: note: suggested alternative: ‘end’ std::bind(std::forward(f), std::forward(args)...)); ^~~~ end At global scope: cc1plus: warning: unrecognized command line option ‘-Wno-vla-extension’ cc1plus: warning: unrecognized command line option ‘-Wno-deprecated-register’ -- 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 33815] Idea: Extend @available so that it can imply an upper bound too
https://bugs.llvm.org/show_bug.cgi?id=33815 Nico Weber changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|REOPENED --- Comment #1 from Nico Weber --- ...if this was implemented, then -Wdeprecated-declaration could fire more often: Currently, it only fires if the deployment target is newer than where a function was deprecated. If this was implemented, then it could fire in regions whose availability is higher than where a function was deprecated. -- 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 33690] [X86][AVX512] Add support for ISD::ROTL/ISD::ROTR
https://bugs.llvm.org/show_bug.cgi?id=33690 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- rL308177 -- 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] The fixup referring to nop or nop-like instruction
This is duplicate sent to llvm-dev, but llvm-bugs looks a better place to ask. Compiled Xalan (one of SPEC2006 programs) with -O2 level in llvm 3.9.0, I have discovered the fixup of the jmp instruction at 0x4143FF is pointing to nop instruction (at 0x414175) instead of the next instruction at 0x414180. .text:00414175 nop word ptr [rax+rax+h] .text:00414180 mov rax, [r14] .text:00414183 mov rbx, [rax+0F8h] ... .text:004143F7 mov rdi, rbx .text:004143FA call___cxa_throw .text:004143FF jmp loc_414175 ... The following is another example that the unconditional branch (0x460025) points to *nop-like* instruction (xchg ax, ax @0x46003e) instead of the next instruction (0x460040). ... .text:00460025 jmp short loc_46003E .text:00460027 xor ebp, ebp .text:00460029 jmp loc_4602F9 .text:0046002E align 10h .text:00460030 lea edx, [rax+1] .text:00460033 mov [r12+4], edx .text:00460038 mov eax, eax .text:0046003A mov [rcx+rax*2], bp .text:0046003E xchgax, ax .text:00460040 mov rdi, [rbx+50h] ; this ... Xalan is the only case that has this particular issue of all SPEC - 13 fixups in total point to 3 locations that contain either nop or nop-like instructions. I understand there is no problem to execute the binary but why LLVM emits the binary that has fixups referring to NOP (MC alignment fragment), not a legitimate code fragment (or logical basic block)? Is this expected? Thanks! Best Regards, Hyungjoon Koo (Kevin) ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25275] Bad Thumb2 code generated, SUB.W SP,
https://bugs.llvm.org/show_bug.cgi?id=25275 Brian G. Lucas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Brian G. Lucas --- *** This bug has been marked as a duplicate of bug 23772 *** -- 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 33818] New: segfault in opt
https://bugs.llvm.org/show_bug.cgi?id=33818 Bug ID: 33818 Summary: segfault in opt Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: bage...@gmail.com CC: llvm-bugs@lists.llvm.org When compiling for arm cortex-m3, a seqfault in opt happens. It appears that someone is passing Ty=0 to ARMTargetLowering::isLegalAddressingMode. Backtrace follows: #0 llvm::ARMTargetLowering::isLegalAddressingMode (this=0x348de10, DL=..., AM=..., Ty=0x0, AS=0) at /home/bgl/work/llvm/lib/Target/ARM/ARMISelLowering.cpp:12384 #1 0x009c2778 in llvm::BasicTTIImplBase::isLegalAddressingMode (AddrSpace=, Scale=0, HasBaseReg=, BaseOffset=0, BaseGV=0x3320ca8, Ty=, this=0x3428c58) at /home/bgl/work/llvm/include/llvm/CodeGen/BasicTTIImpl.h:119 #2 llvm::TargetTransformInfoImplCRTPBase::getGEPCost ( Operands=..., Ptr=, PointeeType=, this=0x3428c58) at /home/bgl/work/llvm/include/llvm/Analysis/TargetTransformInfoImpl.h:681 #3 llvm::BasicTTIImplBase::getGEPCost (Operands=..., Ptr=, PointeeType=, this=0x3428c58) at /home/bgl/work/llvm/include/llvm/CodeGen/BasicTTIImpl.h:155 #4 llvm::TargetTransformInfoImplCRTPBase::getUserCost ( Operands=..., U=, this=0x3428c58) at /home/bgl/work/llvm/include/llvm/Analysis/TargetTransformInfoImpl.h:709 #5 llvm::TargetTransformInfo::Model::getUserCost ( this=0x3428c50, U=, Operands=...) at /home/bgl/work/llvm/include/llvm/Analysis/TargetTransformInfo.h:1047 #6 0x0126b808 in llvm::TargetTransformInfo::getUserCost ( this=this@entry=0x33527e0, U=U@entry=0x3323158, Operands=...) at /home/bgl/work/llvm/lib/Analysis/TargetTransformInfo.cpp:100 #7 0x012d615d in llvm::TargetTransformInfo::getUserCost ( this=this@entry=0x33527e0, U=U@entry=0x3323158) at /home/bgl/work/llvm/include/llvm/Analysis/TargetTransformInfo.h:234 #8 0x01bad561 in ComputeSpeculationCost (TTI=..., I=0x3323158) at /home/bgl/work/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:301 #9 SpeculativelyExecuteBB (BI=BI@entry=0x33230f8, ThenBB=0x3322f50, TTI=...) at /home/bgl/work/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1942 #10 0x01bb53d2 in (anonymous namespace)::SimplifyCFGOpt::SimplifyCondBranch (Builder=..., BI=0x33230f8, this=0x7fffd1a0) at /home/bgl/work/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:5804 #11 (anonymous namespace)::SimplifyCFGOpt::run (BB=0x3321020, this=0x7fffd1a0) at /home/bgl/work/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:5955 #12 llvm::SimplifyCFG (BB=0x3321020, TTI=..., BonusInstThreshold=BonusInstThreshold@entry=1, AC=AC@entry=0x331d030, LoopHeaders=LoopHeaders@entry=0x7fffd420, LateSimplifyCFG=LateSimplifyCFG@entry=false) at /home/bgl/work/llvm/lib/Transforms/Utils/SimplifyCFG.cpp:5995 #13 0x01a27d20 in iterativelySimplifyCFG (F=..., TTI=..., AC=AC@entry=0x331d030, BonusInstThreshold=BonusInstThreshold@entry=1, LateSimplifyCFG=LateSimplifyCFG@entry=false) at /home/bgl/work/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:149 #14 0x01a27f20 in simplifyFunctionCFG (F=..., TTI=..., AC=0x331d030, BonusInstThreshold=1, LateSimplifyCFG=) at /home/bgl/work/llvm/lib/Transforms/Scalar/SimplifyCFGPass.cpp:164 ---Type to continue, or q to quit--- #15 0x0160db32 in llvm::FPPassManager::runOnFunction (this=0x346bff0, F=...) at /home/bgl/work/llvm/lib/IR/LegacyPassManager.cpp:1514 #16 0x0160dc5e in llvm::legacy::FunctionPassManagerImpl::run ( this=0x346bb30, F=...) at /home/bgl/work/llvm/lib/IR/LegacyPassManager.cpp:1463 #17 0x0160e166 in llvm::legacy::FunctionPassManager::run ( this=this@entry=0x326fee0, F=...) at /home/bgl/work/llvm/lib/IR/LegacyPassManager.cpp:1387 #18 0x0069ad04 in main (argc=, argv=0x7fffdf68) at /home/bgl/work/llvm/tools/opt/opt.cpp:704 (gdb) up #1 0x009c2778 in llvm::BasicTTIImplBase::isLegalAddressingMode (AddrSpace=, Scale=0, HasBaseReg=, BaseOffset=0, BaseGV=0x3320ca8, Ty=, this=0x3428c58) at /home/bgl/work/llvm/include/llvm/CodeGen/BasicTTIImpl.h:119 -- 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 33819] New: Round executable PT_LOAD to page size and pad it traps
https://bugs.llvm.org/show_bug.cgi?id=33819 Bug ID: 33819 Summary: Round executable PT_LOAD to page size and pad it traps Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: rafael.espind...@gmail.com CC: llvm-bugs@lists.llvm.org When not using a linker script with SECTIONS we should probably round the size of executable PT_LOAD to a page size and pad it with traps. The reasoning is that if we don't do it any tool editing the file can remove the traps. Currently even lld will put non SHF_ALLOC bits if the executable PT_LOAD is at the end. There was an old attempt at it in D33630. We can hopefully make it simpler now. -- 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 33820] New: After r307364, some versioned symbols do not appear in .so files
https://bugs.llvm.org/show_bug.cgi?id=33820 Bug ID: 33820 Summary: After r307364, some versioned symbols do not appear in .so files Product: lld Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: dimi...@andric.com CC: llvm-bugs@lists.llvm.org Created attachment 18806 --> https://bugs.llvm.org/attachment.cgi?id=18806&action=edit Minimized test case for symbol versioning problem As reported on https://reviews.llvm.org/rL307364, after this change I got errors while linking the FreeBSD base system, similar to: ld.lld: error: undefined symbol: openat >>> referenced by dma-mbox-create.c:175 >>> (/home/dim/src/clang500-import/contrib/dma/dma-mbox-create.c:175) >>> dma-mbox-create.o:(main) It turns out openat is a versioned symbol, which appears twice in libc.so.7: $ readelf -sW /lib/libc.so.7 | grep -w openat 3087: 0004e2e0 203 FUNCWEAK DEFAULT 11 openat@FBSD_1.1 3088: 0004e2e0 203 FUNCWEAK DEFAULT 11 openat@@FBSD_1.2 When doing the link with lld, on aarch64, the openat@@FBSD_1.2 version disappears, for some reason. I've attached a minimized test case in a tarball. There is a Makefile in the extracted directory, which links with both ld.bfd and ld.ldd, and shows the difference in output. -- 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 33728] clang aborts when compiling
https://bugs.llvm.org/show_bug.cgi?id=33728 Christopher Nelson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX -- 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 33821] New: After r307100, segfaults when linking FreeBSD aarch64 kernel
https://bugs.llvm.org/show_bug.cgi?id=33821 Bug ID: 33821 Summary: After r307100, segfaults when linking FreeBSD aarch64 kernel Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: dimi...@andric.com CC: llvm-bugs@lists.llvm.org As reported on https://reviews.llvm.org/rL307100, after this change linking the FreeBSD aarch64 kernel results in lld segfaulting: Thread 1 received signal SIGSEGV, Segmentation fault. lld::elf::OutputSection::addSection (this=0x0, S=0x813b2d008) at /home/dim/src/llvm-trunk/tools/lld/ELF/OutputSections.cpp:84 84Sections.push_back(S); (gdb) bt #0 lld::elf::OutputSection::addSection (this=0x0, S=0x813b2d008) at /home/dim/src/llvm-trunk/tools/lld/ELF/OutputSections.cpp:84 #1 0x009506eb in (anonymous namespace)::Writer >::addPredefinedSections (this=0x7fff6e30) at /home/dim/src/llvm-trunk/tools/lld/ELF/Writer.cpp:1338 #2 0x00949423 in (anonymous namespace)::Writer >::finalizeSections (this=0x7fff6e30) at /home/dim/src/llvm-trunk/tools/lld/ELF/Writer.cpp:1243 #3 0x00914495 in (anonymous namespace)::Writer >::run (this=0x7fff6e30) at /home/dim/src/llvm-trunk/tools/lld/ELF/Writer.cpp:207 #4 0x00973192 in lld::elf::writeResult > () at /home/dim/src/llvm-trunk/tools/lld/ELF/Writer.cpp:126 #5 0x0066c7ff in lld::elf::LinkerDriver::link > (this=0x805ce2000, Args=...) at /home/dim/src/llvm-trunk/tools/lld/ELF/Driver.cpp:1056 #6 0x00655585 in lld::elf::LinkerDriver::main (this=0x805ce2000, ArgsArr=..., CanExitEarly=true) at /home/dim/src/llvm-trunk/tools/lld/ELF/Driver.cpp:386 #7 0x006547a3 in lld::elf::link (Args=..., CanExitEarly=true, Error=...) at /home/dim/src/llvm-trunk/tools/lld/ELF/Driver.cpp:85 #8 0x00457809 in main (Argc=1245, Argv=0x7fff8580) at /home/dim/src/llvm-trunk/tools/lld/tools/lld/lld.cpp:104 (gdb) up #1 0x009506eb in (anonymous namespace)::Writer >::addPredefinedSections (this=0x7fff6e30) at /home/dim/src/llvm-trunk/tools/lld/ELF/Writer.cpp:1338 1338 Cmd->Sec->addSection(Sentinel); (gdb) print Cmd->Sec $5 = (lld::elf::OutputSection *) 0x0 At this point findSectionCommand() was looping through Script->Opt.Commands, found a not-completely initialized .ARM.exidx section, which still had its null Sec member. Reverting the findSectionCommand() implementation to its previous version prevents crashing, but it may not be the correct solution The reproduction test case is unfortunately too large to be attached, find it here: http://www.andric.com/freebsd/clang/lld-arm64-segfault.tar.xz (18 MiB) -- 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 33822] New: DW_AT_decl_file for DW_TAG_imported_declaration is bogus
https://bugs.llvm.org/show_bug.cgi?id=33822
Bug ID: 33822
Summary: DW_AT_decl_file for DW_TAG_imported_declaration is
bogus
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: apra...@apple.com
CC: llvm-bugs@lists.llvm.org
DIImportedEntity has a line number, but not a file field. To determine the
decl_line/decl_file we combine the line number from the DIImportedEntity with
the file from the DIImportedEntity's scope.
DIE *DwarfCompileUnit::constructImportedEntityDIE(
const DIImportedEntity *Module) {
...
addSourceLine(*IMDie, Module->getLine(), Module->getScope()->getFilename(),
Module->getScope()->getDirectory());
...
}
This has odd effects. For example:
-
$ cat using.ii
#line 100 "abc.h"
namespace N { class A; }
#line 200 "using.h"
using N::A;
$ clang++ -g -c using.ii -o using.o
$ dwarfdump using.o
0x0029: TAG_imported_declaration [4]
AT_decl_file( "using.ii" )
AT_decl_line( 200 )
AT_import( {0x0023} )
-
similarly:
#line 100 "abc.h"
namespace N { class A; }
#line 200 "using.cpp"
namespace M {
using N::A;
}
-->
!4 = !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !5, entity: !6,
line: 201)
!5 = !DINamespace(name: "M", scope: null)
!6 = !DICompositeType(tag: DW_TAG_class_type, name: "A", ...)
!8 = !DINamespace(name: "N", scope: null)
-->
0x001e: TAG_namespace [2] *
AT_name( "M" )
0x0023: TAG_imported_declaration [3]
AT_decl_file( "" ) <-- DINamespace has no file/line
AT_decl_line( 201 )
AT_import( {0x0031} )
-
I think that the correct fix for this is to add a `file:` field to
DIImportedEntity.
--
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 33624] Initializing an array of structs at compile time clang fails when targeting wasm32-unknown-unknown-wasm
https://bugs.llvm.org/show_bug.cgi?id=33624 Dan Gohman changed: What|Removed |Added OS|Linux |other Status|NEW |RESOLVED Resolution|--- |FIXED Hardware|PC |Other --- Comment #3 from Dan Gohman --- This is fixed in r307565. -- 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 33818] segfault in opt
https://bugs.llvm.org/show_bug.cgi?id=33818 Davide Italiano changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Davide Italiano --- There's not enough information to reproduce the issue, I'm afraid. Feel free to reopen when you have a C or IR testcase :) -- 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 33823] New: llvm-symbolizer fails to read symbolnames from a .gnu_debuglink file when using symbol tables
https://bugs.llvm.org/show_bug.cgi?id=33823 Bug ID: 33823 Summary: llvm-symbolizer fails to read symbolnames from a .gnu_debuglink file when using symbol tables Product: libraries Version: 4.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: n...@chello.at CC: llvm-bugs@lists.llvm.org Hello, I am trying to extract information using llvm-symbolize and a executable that uses a '.gnu_debuglink' section to point to the separated debug-information. This works for finding the source-file and -line, but the functionname is always 'dlerror'. Adding the flag -use-symbol-table=false fixes the behavior, but this is unexpected as the help says that entries in the symbol table are "preferred", but they appear to cmpletely disable searching the file with debug information. similarly passing the file with debug-information will result in functionames being available (this file does not have a symboltable) -- 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 33824] New: invoked functions returning structs with -enable-emscripten-cxx-exceptions causes runtime crashes
https://bugs.llvm.org/show_bug.cgi?id=33824
Bug ID: 33824
Summary: invoked functions returning structs with
-enable-emscripten-cxx-exceptions causes runtime
crashes
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: tliv...@google.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18808
--> https://bugs.llvm.org/attachment.cgi?id=18808&action=edit
a small failing example
When -enable-emscripten-cxx-exceptions is used, the
WebAssemblyLowerEmscriptenEHSjLj pass lowers invoke instructions to calls to
calls to @__invoke_SIG functions that take the originally invoked function as a
first argument and have the same return type. If that return type is a struct,
the initial lowering step creates an sret parameter in the first argument
position, bumping the function pointer to the second argument position, which
causes a crash when the sret pointer is used as a function pointer at run time.
To reproduce:
llc exceptions.ll -enable-emscripten-cxx-exceptions -debug
Observe that
%ign = invoke { i32, i8* } @bar(i32 3)
to label %invoke.cont unwind label %lpad
is lowered to
...
%ign = call { i32, i8* } @"__invoke_{i32.i8*}_i32"({ i32, i8* } (i32)*
@bar, i32 3)
...
and later lowered to
...
CALL_VOID , , %vreg2,
%vreg1, %ARGUMENTS, %SP32, %SP64;
I32:%vreg2,%vreg1
...
which has the sret pointer, not the function pointer, as the first argument.
--
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 33818] segfault in opt
https://bugs.llvm.org/show_bug.cgi?id=33818 Brian G. Lucas changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Brian G. Lucas --- That was fast, you didn't give me a chance. The program that triggers the bug is very large, the *.ll is over 17000 lines. It will take an appreciable amount of time to cut it down, if I can. This segfault does not trigger with release 4.0.1. -- 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 33825] New: clang boostrap fails at link time with TLS errors
https://bugs.llvm.org/show_bug.cgi?id=33825
Bug ID: 33825
Summary: clang boostrap fails at link time with TLS errors
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: Sparc
Assignee: unassignedb...@nondot.org
Reporter: fedor.serg...@oracle.com
CC: llvm-bugs@lists.llvm.org
Attempt to (manually) bootstrap clang fails when trying to link tablegen:
[246/1342] Linking CXX executable bin/llvm-tblgen
FAILED: bin/llvm-tblgen
: && /export/home/fsergeev/LLVM/llvm-build/sparc-50/bin/clang++ -m64 -fPIC
-fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers
-pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics
-ffunction-sections -fdata-sections -O3 -DNDEBUG -m64
-Wl,-R/export/home/fsergeev/LLVM/llvm-build/sparc-50/lib/sparcv9-Wl,-z
-Wl,discard-unused=sections
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o <...cut
some stuff here..> -o bin/llvm-tblgen lib/libLLVMSupport.a
lib/libLLVMTableGen.a lib/libLLVMSupport.a -lrt -ldl -lcurses -lz -lm
lib/libLLVMDemangle.a && :
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
lib/libLLVMSupport.a(PrettyStackTrace.cpp.o): symbol _ZL20PrettyStackTraceHead:
value 0x3fffc1 does not fit
] elfdump -r ./lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o
| grep HIX22.*_ZL20PrettyStackTraceHead
[4] R_SPARC_TLS_LDO_HIX220x28 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[2] R_SPARC_TLS_LDO_HIX220x24 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[2] R_SPARC_TLS_LDO_HIX220x14 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[2] R_SPARC_TLS_LDO_HIX220x14 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[4] R_SPARC_TLS_LDO_HIX220x2c 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[4] R_SPARC_TLS_LDO_HIX220x2c 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[4] R_SPARC_TLS_LDO_HIX220x2c 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[7] R_SPARC_TLS_LDO_HIX220x64 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[7] R_SPARC_TLS_LDO_HIX220x64 0x3f 0 .text._ZN4llvm
_ZL20PrettyStackTraceHead
[3] R_SPARC_TLS_LDO_HIX220x20 0x3f 0 .text._ZL12Cra
_ZL20PrettyStackTraceHead
It appears that generation of TLS_LDO_HIX22 relocation for sparc is broken.
Reduced testcase:
] cat tls-hix.cc
static thread_local void* StackTraceHead = nullptr;
void* foo() {
return StackTraceHead;
}
int main() {
return !foo();
}
] bin/clang++ tls-hix.cc -std=c++11 -m64
ld: fatal: relocation error: R_SPARC_TLS_LE_HIX22: file
/var/tmp/tls-hix-548455.o: symbol _ZL14StackTraceHead: value 0x3fffc1
does not fit
clang-5.0: error: linker command failed with exit code 1 (use -v to see
invocation)
]
--
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 33826] New: Assertion `Invalid Inst-size!!!' in X86InterleavedAccess.cpp
https://bugs.llvm.org/show_bug.cgi?id=33826
Bug ID: 33826
Summary: Assertion `Invalid Inst-size!!!' in
X86InterleavedAccess.cpp
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: paul_robin...@playstation.sony.com
CC: llvm-bugs@lists.llvm.org
Created attachment 18809
--> https://bugs.llvm.org/attachment.cgi?id=18809&action=edit
Full crash report
$ cat bz180454.cpp
typedef double __attribute__((ext_vector_type(4))) double4;
double4 a;
double4 test161_funcid33732(double4 b) {
return __builtin_shufflevector(a.wxxx, b, 0, 4, 0, 0);
}
$ clang -c -O2 bz180454.cpp -march=btver2
clang-5.0:
/home/probinson/projects/llvm-org/trunk/llvm/lib/Target/X86/X86InterleavedAccess.cpp:130:
void {anonymous}::X86InterleavedAccessGroup::decompose(llvm::Instruction*,
unsigned int, llvm::VectorType*, llvm::SmallVectorImpl&):
Assertion `VecTy->isVectorTy() && DL.getTypeSizeInBits(VecTy) >=
DL.getTypeSizeInBits(SubVecTy) * NumSubVectors && "Invalid Inst-size!!!"'
failed.
I don't get a failure with r306050, but it fails with r306100.
Most likely suspect looks like r306068.
--
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 33827] New: _Generic associated list is misformatted
https://bugs.llvm.org/show_bug.cgi?id=33827 Bug ID: 33827 Summary: _Generic associated list is misformatted Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: compn...@compnerd.org CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org ``` #define __SSIZE_TYPE__ \ __typeof__(_Generic((__SIZE_TYPE__)0, \ unsigned long long int: (long long int)0, \ unsigned long int: (long int)0, \ unsigned int: (int)0, \ unsigned short: (short)0, \ unsigned char: (signed char)0)) ``` is formatted as ``` #define __SSIZE_TYPE__ \ __typeof__(_Generic((__SIZE_TYPE__)0, unsigned long long int \ : (long long int)0, unsigned long int \ : (long int)0, unsigned int \ : (int)0, unsigned short \ : (short)0, unsigned char \ : (signed char)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 33828] New: Crash in X86DAGToDAGISel::RunSDNodeXForm: "getConstant with a uint64_t value that doesn't fit in the type!"
https://bugs.llvm.org/show_bug.cgi?id=33828
Bug ID: 33828
Summary: Crash in X86DAGToDAGISel::RunSDNodeXForm: "getConstant
with a uint64_t value that doesn't fit in the type!"
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: babo...@gmail.com
CC: llvm-bugs@lists.llvm.org
clang trunk, rev 308072, x86_64.
Bug reproduces for -march=haswell|broadwell|skx
> cat f.cpp
extern unsigned short var_22;
extern signed char var_32;
extern unsigned short var_53;
extern signed char var_56;
extern signed char var_62;
extern signed char var_580;
void foo() {
var_53 = 0;
if (var_56)
;
else {
if (var_32)
var_53 = var_22 || var_62 / 31;
if (var_580 & ~((0 || 309201625365528537) << 2 * var_53 / 71 - 3))
var_62 = 0;
}
}
> clang++ -w -O2 -march=haswell -c f.cpp
clang-5.0:
/home/dybaboki/llvm/llvm-trunk-20170714/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1088:
llvm::SDValue llvm::SelectionDAG::getConstant(uint64_t, const llvm::SDLoc &,
llvm::EVT, bool, bool): Assertion `(EltVT.getSizeInBits() >= 64 ||
(uint64_t)((int64_t)Val >> EltVT.getSizeInBits()) + 1 < 2) && "getConstant with
a uint64_t value that doesn't fit in the type!"' failed.
#0 0x0130a23f llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x130a23f)
#1 0x0130a546 SignalHandler(int)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x130a546)
#2 0x7f89e5eb0370 __restore_rt (/lib64/libpthread.so.0+0xf370)
#3 0x7f89e4a2d1d7 __GI_raise (/lib64/libc.so.6+0x351d7)
#4 0x7f89e4a2e8c8 __GI_abort (/lib64/libc.so.6+0x368c8)
#5 0x7f89e4a26146 __assert_fail_base (/lib64/libc.so.6+0x2e146)
#6 0x7f89e4a261f2 (/lib64/libc.so.6+0x2e1f2)
#7 0x019fe7c7
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x19fe7c7)
#8 0x0081fe62 (anonymous
namespace)::X86DAGToDAGISel::RunSDNodeXForm(llvm::SDValue, unsigned int)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x81fe62)
#9 0x01a3c123 llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*,
unsigned char const*, unsigned int)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x1a3c123)
#10 0x00819ae6 (anonymous
namespace)::X86DAGToDAGISel::Select(llvm::SDNode*)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x819ae6)
#11 0x01a35c7a llvm::SelectionDAGISel::DoInstructionSelection()
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x1a35c7a)
#12 0x01a34c92 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x1a34c92)
#13 0x01a32460
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x1a32460)
#14 0x01a2ede6
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x1a2ede6)
#15 0x008158d1 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x8158d1)
#16 0x00bcb794
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0xbcb794)
#17 0x00ec598f llvm::FPPassManager::runOnFunction(llvm::Function&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0xec598f)
#18 0x00ec5be3 llvm::FPPassManager::runOnModule(llvm::Module&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0xec5be3)
#19 0x00ec60d6 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0xec60d6)
#20 0x0147a64f clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout
const&, llvm::Module*, clang::BackendAction,
std::unique_ptr >)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x147a64f)
#21 0x01b1d382
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x1b1d382)
#22 0x01f80396 clang::ParseAST(clang::Sema&, bool, bool)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x1f80396)
#23 0x017f5498 clang::FrontendAction::Execute()
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x17f5498)
#24 0x017ba421
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x17ba421)
#25 0x0187a1c7
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/home/dybaboki/llvm/bin-trunk-20170714/bin/clang-5.0+0x187a1c7)
#26 0x00770e2f cc1_main(llvm::ArrayRef, char const*,
[llvm-bugs] [Bug 33801] OS X uses 'module' as member name, conflicts with module TS keyword 'module'
https://bugs.llvm.org/show_bug.cgi?id=33801 Bruno Cardoso Lopes changed: What|Removed |Added Component|C++'1z |Modules CC||dgre...@apple.com, ||llvm-bugs@lists.llvm.org -- 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 33829] New: implement a structured clang-fuzzer (aka clang-proto-fuzzer)
https://bugs.llvm.org/show_bug.cgi?id=33829 Bug ID: 33829 Summary: implement a structured clang-fuzzer (aka clang-proto-fuzzer) Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: masc...@google.com Reporter: k...@google.com CC: llvm-bugs@lists.llvm.org Created attachment 18812 --> https://bugs.llvm.org/attachment.cgi?id=18812&action=edit cxx_proto.proto I have a prototype of a "structured" fuzzer for clang based on https://github.com/google/libprotobuf-mutator and tools/clang/tools/clang-fuzzer/ClangFuzzer.cpp. The idea is that we describe a subset of C++ as a protobuf, implement a protobuf=>C++ serialization, and mutate the protobufs during guided fuzzing. The prototype has already discovered several bugs: https://bugs.llvm.org/show_bug.cgi?id=33747 https://bugs.llvm.org/show_bug.cgi?id=33749 https://bugs.llvm.org/show_bug.cgi?id=33494 and so it's time to make it available in LLVM trunk. The tricky part is that this fuzzer depends on the code that is not part of the regular LLVM tree nor it's regular deps. We'll need: * relatively recent libprotobuf-dev * fresh libprotobuf-mutator I propose to implement clang-proto-fuzzer under a cmake flag (off by default), so that the default build doesn't depend on libprotobuf-dev/libprotobuf-mutator. (An alternative is to drag this code into the LLVM tree, which is highly unpleasant). I suggest to add ClangProtoFuzzer.cpp adjacent to ClangFuzzer.cpp (both should probably share some code) and add separate files * proto description for C++-like language. * proto=>C++ serialization code. * simple driver to convert a proto to C++ My prototypes for these are attached. ClangProtoFuzzer will need to support LLVM flags (via libFuzzer's -ignore_remaining_args=1) so that we can fuzz non-default configurations (e.g. non-default '-triple'). -- 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 33830] New: [AVX] clang does not respect streaming store intrinsics
https://bugs.llvm.org/show_bug.cgi?id=33830
Bug ID: 33830
Summary: [AVX] clang does not respect streaming store
intrinsics
Product: clang
Version: 4.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: manfred.liebm...@uni-graz.at
CC: llvm-bugs@lists.llvm.org
The AVX streaming store intrinsic _mm256_stream_pd is not translated by clang
4.0.1 to VMOVNTPD but to VMOVUPD. This leads to severe performance degradation.
This bug is not present in the official release of clang 3.8.0.
This seems to be related to the changes introduced with
__builtin_nontemporal_store.
Streaming stores with SSE instruction set seems to be not affected.
Sample code:
#include
int main() {
int n = 1024;
//AVX
double* x = (double*)_mm_malloc( sizeof(double)*n, 32 );
__m256d a = _mm256_set1_pd(2017.0717);
for (int i = 0; i < 1024; i+=4) {
_mm256_stream_pd(x+i, a);
}
//SEE
double* y = (double*)_mm_malloc( sizeof(double)*n, 32 );
__m128d b = _mm_set1_pd(2017.0717);
for (int i = 0; i < 1024; i+=4) {
_mm_stream_pd(y+i, b);
}
return 0;
}
# clang -S -O3 -march=native -o bug.s bug.c
--
Assembler code for clang 4.0.1
==
.section__TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 12
.section__TEXT,__literal8,8byte_literals
.p2align3
LCPI0_0:
.quad 4656585990599183486 ## double 2017.0717
.section__TEXT,__literal16,16byte_literals
.p2align4
LCPI0_1:
.quad 4656585990599183486 ## double 2017.0717
.quad 4656585990599183486 ## double 2017.0717
.section__TEXT,__text,regular,pure_instructions
.globl _main
.p2align4, 0x90
_main: ## @main
.cfi_startproc
## BB#0:
pushq %rbp
Lcfi0:
.cfi_def_cfa_offset 16
Lcfi1:
.cfi_offset %rbp, -16
movq%rsp, %rbp
Lcfi2:
.cfi_def_cfa_register %rbp
subq$16, %rsp
leaq-8(%rbp), %rdi
movl$32, %esi
movl$8192, %edx ## imm = 0x2000
callq _posix_memalign
xorl%ecx, %ecx
testl %eax, %eax
movq-8(%rbp), %rax
cmovneq %rcx, %rax
vbroadcastsdLCPI0_0(%rip), %ymm0
.p2align4, 0x90
LBB0_1: ## =>This Inner Loop Header: Depth=1
vmovups %ymm0, (%rax,%rcx,8)
vmovups %ymm0, 32(%rax,%rcx,8)
vmovups %ymm0, 64(%rax,%rcx,8)
vmovups %ymm0, 96(%rax,%rcx,8)
vmovups %ymm0, 128(%rax,%rcx,8)
vmovups %ymm0, 160(%rax,%rcx,8)
vmovups %ymm0, 192(%rax,%rcx,8)
vmovups %ymm0, 224(%rax,%rcx,8)
vmovups %ymm0, 256(%rax,%rcx,8)
vmovups %ymm0, 288(%rax,%rcx,8)
vmovups %ymm0, 320(%rax,%rcx,8)
vmovups %ymm0, 352(%rax,%rcx,8)
vmovups %ymm0, 384(%rax,%rcx,8)
vmovups %ymm0, 416(%rax,%rcx,8)
vmovups %ymm0, 448(%rax,%rcx,8)
vmovups %ymm0, 480(%rax,%rcx,8)
addq$64, %rcx
cmpq$1024, %rcx ## imm = 0x400
jl LBB0_1
## BB#2:
leaq-8(%rbp), %rdi
movl$32, %esi
movl$8192, %edx ## imm = 0x2000
vzeroupper
callq _posix_memalign
xorl%ecx, %ecx
testl %eax, %eax
movq-8(%rbp), %rax
cmovneq %rcx, %rax
vmovaps LCPI0_1(%rip), %xmm0## xmm0 = [2.017072e+03,2.017072e+03]
.p2align4, 0x90
LBB0_3: ## =>This Inner Loop Header: Depth=1
vmovntps%xmm0, (%rax,%rcx,8)
vmovntps%xmm0, 32(%rax,%rcx,8)
vmovntps%xmm0, 64(%rax,%rcx,8)
vmovntps%xmm0, 96(%rax,%rcx,8)
vmovntps%xmm0, 128(%rax,%rcx,8)
vmovntps%xmm0, 160(%rax,%rcx,8)
vmovntps%xmm0, 192(%rax,%rcx,8)
vmovntps%xmm0, 224(%rax,%rcx,8)
vmovntps%xmm0, 256(%rax,%rcx,8)
vmovntps%xmm0, 288(%rax,%rcx,8)
vmovntps%xmm0, 320(%rax,%rcx,8)
vmovntps%xmm0, 352(%rax,%rcx,8)
vmovntps%xmm0, 384(%rax,%rcx,8)
vmovntps%xmm0, 416(%rax,%rcx,8)
vmovntps%xmm0, 448(%rax,%rcx,8)
vmovntps%xmm0, 480(%rax,%rcx,8)
addq$64, %rcx
cmpq$1024, %rcx ## imm = 0x400
jl LBB0_3
## BB#4:
xorl%eax, %eax
addq$16, %rsp
popq%rbp
retq
.cfi_endpr
[llvm-bugs] [Bug 33831] New: cfi-icall + ThinLTO program containing indirect call to inline function fails to link
https://bugs.llvm.org/show_bug.cgi?id=33831
Bug ID: 33831
Summary: cfi-icall + ThinLTO program containing indirect call
to inline function fails to link
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: pe...@pcc.me.uk
CC: llvm-bugs@lists.llvm.org
$ cat icall.cpp
inline void f() {}
void g(void (*p)()) {
p();
}
int main() {
g(f);
}
$ clang++ icall.cpp -fsanitize=cfi-icall -flto=thin -fuse-ld=lld -O2
ld.lld: error: undefined symbol: f() (.cfi)
>>> referenced by ld-temp.o
>>> lto.tmp:(f())
clang-5.0: error: linker command failed with exit code 1 (use -v to see
invocation)
--
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 33832] New: cfi-icall + ThinLTO: no jump table entry created for functions defined in both ThinLTO module and merged module
https://bugs.llvm.org/show_bug.cgi?id=33832
Bug ID: 33832
Summary: cfi-icall + ThinLTO: no jump table entry created for
functions defined in both ThinLTO module and merged
module
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Interprocedural Optimizations
Assignee: unassignedb...@nondot.org
Reporter: pe...@pcc.me.uk
CC: llvm-bugs@lists.llvm.org
$ cat icall1.cpp
inline void f() {}
void sink(void (*)());
static struct A {
A() { sink(f); }
} a;
$ cat icall2.cpp
inline void f() {}
void sink(void (*)()) {}
int main() {
void (*p)() = f;
p();
}
$ clang++ icall{1,2}.cpp -fsanitize=cfi-icall -flto=thin -fuse-ld=lld -O2
-fno-sanitize-trap=cfi-icall -g
$ ./a.out
icall2.cpp:7:3: runtime error: control flow integrity check for type 'void ()'
failed during indirect function call
/tmp/icall1.cpp:1: note: f() defined 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 33772] compiler crash on the code with @llvm.x86.avx512.gather.dpi.512 intrinsic
https://bugs.llvm.org/show_bug.cgi?id=33772 Craig Topper changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Craig Topper --- This isn't valid code since we require the gather scale to be constant, but we shouldn't assert. r308267 fixes the assertion failure and turns this into an instruction selection error instead. -- 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
