[llvm-bugs] [Bug 39417] InnerLoopVectorizer::emitSCEVChecks(llvm::Loop *, llvm::BasicBlock *): Assertion `!Cost->foldTailByMasking() && "Cannot check stride when folding tail"' failed.
https://bugs.llvm.org/show_bug.cgi?id=39417 ayal.z...@intel.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39497] [LoopVectorizer] clang crashes on valid code at -O3 on x86_64-linux-gnu: Assertion `!Cost->fol dTailByMasking() && "Cannot check stride when folding tail"' failed
https://bugs.llvm.org/show_bug.cgi?id=39497 ayal.z...@intel.com changed: What|Removed |Added Fixed By Commit(s)||345959 Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11259 in oss-fuzz: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator
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-11-05 Type: Bug New issue 11259 by ClusterFuzz-External: llvm/clang-fuzzer: Stack-overflow in GetFullTypeForDeclarator https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11259 Detailed report: https://oss-fuzz.com/testcase?key=5686473907503104 Project: llvm Fuzzer: libFuzzer_llvm_clang-fuzzer Fuzz target binary: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7fffbe752f18 Crash State: GetFullTypeForDeclarator clang::Sema::GetTypeForDeclarator clang::Sema::ActOnBlockArguments Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810160226:201810170227 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5686473907503104 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 39552] New: Coverage option(--coverage) makes a compile error when the souce-code requires -mcmodel=large.
https://bugs.llvm.org/show_bug.cgi?id=39552 Bug ID: 39552 Summary: Coverage option(--coverage) makes a compile error when the souce-code requires -mcmodel=large. Product: compiler-rt Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P Component: compiler-rt Assignee: unassignedb...@nondot.org Reporter: ueno.masak...@jp.fujitsu.com CC: llvm-bugs@lists.llvm.org Created attachment 21081 --> https://bugs.llvm.org/attachment.cgi?id=21081&action=edit The log of compile-error and options The libclang_rt.profile-x86_64.a that is used by --coverage is not available when the date of user program exceeds 2GB. When generating this library should I use -mcmodel=large or generate as a dynamic library? Are there any problem when use -mcmodel=large or generate/use dynamic library? (I think the execution performance will be deteriorated if using -mcmodel=large. Any other problems?) The attached file contains the log of compile-error and options. -- 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 39553] New: Fix "LLVM ERROR: ran out of registers during register allocation" for LDDWRdPtrQ with the Z register
https://bugs.llvm.org/show_bug.cgi?id=39553
Bug ID: 39553
Summary: Fix "LLVM ERROR: ran out of registers during register
allocation" for LDDWRdPtrQ with the Z register
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AVR
Assignee: unassignedb...@nondot.org
Reporter: m...@dylanmckay.io
CC: llvm-bugs@lists.llvm.org
We have an AVR-specific workaround for a limitation of the register
allocator that only exposes itself on targets with high register
contention like AVR, which only has three pointer registers.
The three pointer registers are X, Y, and Z.
In most nontrivial functions, Y is reserved for the frame pointer,
as per the calling convention. This leaves X and Z. Some instructions,
such as LPM ("load program memory"), are only defined for the Z
register. Sometimes this just leaves X.
When the backend generates a LDDWRdPtrQ instruction with Z as the
destination pointer, it usually trips up the register allocator
with this error message:
LLVM ERROR: ran out of registers during register allocation
Here is a description from the author Peter Nimmervoll
As far as I understand the problem occurs when LDDWRdPtrQ uses
the ptrdispregs register class as target register. This should work, but
the allocator can't deal with this for some reason. So from my testing,
it seams like (and I might be totally wrong on this) the allocator reserves
the Z register for the ICALL instruction and then the register class
ptrdispregs only has 1 register left and we can't use Y for source and
destination. Removing the Z register from DREGS fixes the problem but
removing Y register does not.
More information about the original bug and its investigation can be found on
the avr-rust issue
tracker at https://github.com/avr-rust/rust/issues/37.
--
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 39554] New: Add a unit test for frame index expansion
https://bugs.llvm.org/show_bug.cgi?id=39554 Bug ID: 39554 Summary: Add a unit test for frame index expansion Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: AVR Assignee: unassignedb...@nondot.org Reporter: m...@dylanmckay.io CC: llvm-bugs@lists.llvm.org In avr-rust bug #112, we encountered a backend bug caused by invalid expansion of a FRMIDX instruction into a MOVWRdRr instruction. The backend would leave an extraneous operand from the original FRMIDX that was not consistent with the definition of MOVWRdRr. This would trigger an assertion: Assertion failed: ((isImpReg || Op.isRegMask() || MCID->isVariadic() || OpNo < MCID->getNumOperands() || isMetaDataOp) && "Trying to add an operand to a machine instr that is already done!"), function addOperand, file llvm/lib/CodeGen/MachineInstr.cpp More informatiob about that bug can be found at: https://github.com/avr-rust/rust/issues/112 We should write unit tests that cover the expansion of FRMIDX nodes into MOVWRdRr 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 39555] New: ppc32 always reserves r2
https://bugs.llvm.org/show_bug.cgi?id=39555
Bug ID: 39555
Summary: ppc32 always reserves r2
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: j...@jms.id.au
CC: llvm-bugs@lists.llvm.org
The PowerPC 32-bit port always reserves r2:
lib/Target/PowerPC/PPCRegisterInfo.cpp:
// The SVR4 ABI reserves r2 and r13
if (Subtarget.isSVR4ABI()) {
// We only reserve r2 if we need to use the TOC pointer. If we have no
// explicit uses of the TOC pointer (meaning we're a leaf function with
// no constant-pool loads, etc.) and we have no potential uses inside an
// inline asm block, then we can treat r2 has an ordinary callee-saved
// register.
const PPCFunctionInfo *FuncInfo = MF.getInfo();
if (!TM.isPPC64() || FuncInfo->usesTOCBasePtr() || MF.hasInlineAsm())
markSuperRegs(Reserved, PPC::R2); // System-reserved register
markSuperRegs(Reserved, PPC::R13); // Small Data Area pointer register
}
This is useful for eg. Linux kernel, but other programs many not need to
reserve r2 and could instead allow the compiler to use it.
In order to support this clang would need a -ffixed-r2 flag (similar to GCC)
that allows programs such Linux to reserve r2.
--
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 39556] New: powerpc port lacks -mmultiple / -mno-multiple
https://bugs.llvm.org/show_bug.cgi?id=39556 Bug ID: 39556 Summary: powerpc port lacks -mmultiple / -mno-multiple Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: j...@jms.id.au CC: llvm-bugs@lists.llvm.org When compiling the Linux kernel, ppc32be platforms will enable the -mmutliple flag. From the GCC man page: -mno-multiple Generate code that uses (does not use) the load multiple word instructions and the store multiple word instructions. These instructions are generated by default on POWER systems, and not generated on PowerPC systems. Do not use -mmultiple on little-endian PowerPC systems, since those instructions do not work when the processor is in little-endian mode. The exceptions are PPC740 and PPC750 which permit these instructions in little-endian mode. For feature parity it would be good if Clang supported this option. -- 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
