[llvm-bugs] [Bug 32708] New: The shift didn't carry out the value in bit-field structure
https://bugs.llvm.org/show_bug.cgi?id=32708
Bug ID: 32708
Summary: The shift didn't carry out the value in bit-field
structure
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: shiva0...@gmail.com
CC: llvm-bugs@lists.llvm.org
According to C99 6.7.2.1
9 A bit-field is interpreted as a signed or unsigned integer type consisting of
the specified number of bits.
So the bit exceed the number of bits after shift should carry out.
In the following case,
x.b:40 initial as 0x0100 should carry out to 0 after (x.b<<32)
struct foo
{
unsigned long long b:40;
} x;
extern void abort (void);
void test1(unsigned long long res)
{
/* The shift is carried out in 40 bit precision. */
if (x.b<<32 != res)
abort ();
}
int main()
{
x.b = 0x0100;
test1(0);
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 32471] Compiler crash on AArch64-linux on test-suite MultiSource/Benchmarks/MiBench with -global-isel-abort=2
https://bugs.llvm.org/show_bug.cgi?id=32471 Kristof Beyls changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Kristof Beyls --- Fixed in r300664 -- 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 32709] New: r300639 broke self-hosting on ARM Linux
https://bugs.llvm.org/show_bug.cgi?id=32709 Bug ID: 32709 Summary: r300639 broke self-hosting on ARM Linux Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: ARM Assignee: unassignedb...@nondot.org Reporter: renato.go...@linaro.org CC: llvm-bugs@lists.llvm.org http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/1349 lib/Target/ARM/ARMFrameLowering.cpp:455: virtual void llvm::ARMFrameLowering::emitPrologue(llvm::MachineFunction &, llvm::MachineBasicBlock &) const: Assertion `getMaxFPOffset(*MF.getFunction(), *AFI) <= FPOffset && "Max FP estimation is wrong"' failed. -- 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 30624] [META][X86] Avoid lowering C intrinsics calls to target-specific LLVM IR intrinsics
https://bugs.llvm.org/show_bug.cgi?id=30624 Bug 30624 depends on bug 30985, which changed state. Bug 30985 Summary: [X86] Replace _mm_stream_load_si128 with __builtin_nontemporal_load https://bugs.llvm.org/show_bug.cgi?id=30985 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 30985] [X86] Replace _mm_stream_load_si128 with __builtin_nontemporal_load
https://bugs.llvm.org/show_bug.cgi?id=30985 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Simon Pilgrim --- Fixed rL300325 (llvm), rL300326 (clang) -- 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 32710] New: PMADDWD optimization on unsigned 16 bit integer
https://bugs.llvm.org/show_bug.cgi?id=32710
Bug ID: 32710
Summary: PMADDWD optimization on unsigned 16 bit integer
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: ilia.tara...@intel.com
CC: llvm-bugs@lists.llvm.org
==test.c==
#include "stdio.h"
#define N 32832
unsigned short a[N];
unsigned int sq_sum(void) {
int i;
unsigned int acc = 0;
for (i = 0; i < N; i++){
acc += a[i] * a[i];
}
return acc;
}
int
main() {
int i;
for (i = 0; i < N; i++) {
a[i] = i;
}
unsigned int acc;
acc = sq_sum();
printf("%u\n", acc);
return 0;
}
==
>>>clang -v
clang version 5.0.0 (trunk 299776)
...
>>>clang -o simple.exe -O2 test.c
>>>clang -o test.exe -O2 -march=skylake-avx512 test.c
>>>./speed.exe
2458652000
>>>./test.exe
2194410848
==
Disas of test.exe(299775):
...
400920: 62 f2 7d 48 33 a0 c0vpmovzxwd 0x6120c0(%rax),%zmm4
400927: 20 61 00
40092a: 62 f2 7d 48 33 a8 e0vpmovzxwd 0x6120e0(%rax),%zmm5
400931: 20 61 00
400934: 62 f2 7d 48 33 b0 00vpmovzxwd 0x612100(%rax),%zmm6
40093b: 21 61 00
40093e: 62 f2 7d 48 33 b8 20vpmovzxwd 0x612120(%rax),%zmm7
400945: 21 61 00
400948: 62 f2 5d 48 40 e4 vpmulld %zmm4,%zmm4,%zmm4
40094e: 62 f2 55 48 40 ed vpmulld %zmm5,%zmm5,%zmm5
400954: 62 f2 4d 48 40 f6 vpmulld %zmm6,%zmm6,%zmm6
40095a: 62 f2 45 48 40 ff vpmulld %zmm7,%zmm7,%zmm7
400960: 62 f1 5d 48 fe c0 vpaddd %zmm0,%zmm4,%zmm0
400966: 62 f1 55 48 fe c9 vpaddd %zmm1,%zmm5,%zmm1
40096c: 62 f1 4d 48 fe d2 vpaddd %zmm2,%zmm6,%zmm2
400972: 62 f1 45 48 fe db vpaddd %zmm3,%zmm7,%zmm3
...
Disas of test.exe(299776):
...
400950: c5 fe 6f a8 c0 20 61vmovdqu 0x6120c0(%rax),%ymm5
400957: 00
400958: c5 fe 6f b0 e0 20 61vmovdqu 0x6120e0(%rax),%ymm6
40095f: 00
400960: c5 fe 6f b8 00 21 61vmovdqu 0x612100(%rax),%ymm7
400967: 00
400968: c5 7e 6f 80 20 21 61vmovdqu 0x612120(%rax),%ymm8
40096f: 00
400970: c5 d5 f5 ed vpmaddwd %ymm5,%ymm5,%ymm5
400974: 62 f3 55 48 3a e8 01vinserti32x8 $0x1,%ymm0,%zmm5,%zmm5
40097b: 62 f1 55 48 fe c9 vpaddd %zmm1,%zmm5,%zmm1
...
but in vpmaddwd integers are multiplied as signed integers, so we receive wrong
answer when arguments are bigger than SHRT_MAX.
===r299776
Index: lib/Target/X86/X86ISelLowering.cpp
===
--- lib/Target/X86/X86ISelLowering.cpp (revision 299775)
+++ lib/Target/X86/X86ISelLowering.cpp (revision 299776)
@@ -34618,6 +34618,51 @@
DAG.getConstant(0, DL, VT), NewCmp);
}
+static SDValue combineLoopMAddPattern(SDNode *N, SelectionDAG &DAG,
+ const X86Subtarget &Subtarget) {
+ SDValue MulOp = N->getOperand(0);
+ SDValue Phi = N->getOperand(1);
+
+ if (MulOp.getOpcode() != ISD::MUL)
+std::swap(MulOp, Phi);
+ if (MulOp.getOpcode() != ISD::MUL)
+return SDValue();
+
+ ShrinkMode Mode;
+ if (!canReduceVMulWidth(MulOp.getNode(), DAG, Mode))
+return SDValue();
+
+ EVT VT = N->getValueType(0);
+
+ unsigned RegSize = 128;
+ if (Subtarget.hasBWI())
+RegSize = 512;
+ else if (Subtarget.hasAVX2())
+RegSize = 256;
+ unsigned VectorSize = VT.getVectorNumElements() * 16;
+ // If the vector size is less than 128, or greater than the supported
RegSize,
+ // do not use PMADD.
+ if (VectorSize < 128 || VectorSize > RegSize)
+return SDValue();
+
+ SDLoc DL(N);
+ EVT ReducedVT = EVT::getVectorVT(*DAG.getContext(), MVT::i16,
+ VT.getVectorNumElements());
+ EVT MAddVT = EVT::getVectorVT(*DAG.getContext(), MVT::i32,
+VT.getVectorNumElements() / 2);
+
+ // Shrink the operands of mul.
+ SDValue N0 = DAG.getNode(ISD::TRUNCATE, DL, ReducedVT,
MulOp->getOperand(0));
+ SDValue N1 = DAG.getNode(ISD::TRUNCATE, DL, ReducedVT,
MulOp->getOperand(1));
+
+ // Madd vector size is half of the original vector size
+ SDValue Madd = DAG.getNode(X86ISD::VPMADDWD, DL, MAddVT, N0, N1);
+ // Fill the rest of the output with 0
+ SDValue Zero = getZeroVector(Madd.getSimpleValueType(), Subtarget, DAG, DL);
+ SDValue Concat = DAG.getNode(ISD::CONCAT_VECTORS, DL, VT, Madd, Zero);
+ return DAG.getNode(ISD::ADD, DL, VT, Concat, Phi);
+}
+
static SDValue combineLoopSADPattern(SDNode *N, SelectionDAG &DAG,
const X86Subtarget &Subt
[llvm-bugs] [Bug 32697] assert fail in IR/Value.cpp
http://bugs.llvm.org/show_bug.cgi?id=32697 Davide Italiano changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Davide Italiano --- Committed r300693 -- 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 32711] New: [mc] vmcnt() expcnt() lgkmcnt() helpers to check that value fits into appropriate field
https://bugs.llvm.org/show_bug.cgi?id=32711 Bug ID: 32711 Summary: [mc] vmcnt() expcnt() lgkmcnt() helpers to check that value fits into appropriate field Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: i.am.permi...@gmail.com CC: llvm-bugs@lists.llvm.org vmcnt() expcnt() lgkmcnt() helpers that are used to construct immediate for s_waitcnt instruction does not check that provided value fits into appropriate fields. Example: s_waitcnt vmcnt(666) It's better to produce an error rather than silently truncate values. Also we would like to see additional set of helpers (vmcnt_sat() expcnt_sat() lgkmcnt_sat()) which would produce saturated output. Note that allowable ranges differs on gfx8 and gfx9 hardware. -- 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 32713] New: mips/mipsel i128 sub/add generates wrong code
https://bugs.llvm.org/show_bug.cgi?id=32713
Bug ID: 32713
Summary: mips/mipsel i128 sub/add generates wrong code
Product: libraries
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: MIPS
Assignee: unassignedb...@nondot.org
Reporter: simonas+llvm@kazlauskas.me
CC: llvm-bugs@lists.llvm.org
i128 subtraction on 32bit MIPSes seems to fail to propagate the carry bit from
lower 64 bits to higher 64 bits.
Therefore on x86(_64) the foo function from IR below returns `~0` (i128 with
all bits set), whereas on MIPS it returns something like
_______.
`add i128 %a, %b` where `%a = i128 -1` and `%b = i128 1` seems to also not
produce `0` as a result.
Reproduction IR (subtraction):
target datalayout = "e-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64"
target triple = "mipsel-unknown-linux-gnu"
define i128 @foo(i128, i128) unnamed_addr #0 {
start:
%a = sub i128 %0, %1
ret i128 %a
}
define i32 @main(i32, i8**) unnamed_addr {
start:
%r = tail call i128 @foo(i128 0, i128 1)
%c = icmp ne i128 %r, -1
%x = zext i1 %c to i32
ret i32 %x
}
attributes #0 = { norecurse nounwind readnone uwtable noinline }
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"PIE Level", i32 2}
Reproduction IR (addition):
target datalayout = "e-m:m-p:32:32-i8:8:32-i16:16:32-i64:64-n32-S64"
target triple = "mipsel-unknown-linux-gnu"
define i128 @foo(i128, i128) unnamed_addr #0 {
start:
%a = add i128 %0, %1
ret i128 %a
}
define i32 @main(i32, i8**) unnamed_addr {
start:
%r = tail call i128 @foo(i128 -1, i128 1)
%c = icmp ne i128 %r, 0
%x = zext i1 %c to i32
ret i32 %x
}
attributes #0 = { norecurse nounwind readnone uwtable noinline }
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"PIE Level", i32 2}
Testing procedure:
llc file.ll -filetype=obj && cc file.o && ./a.out && echo "success"
LLVM Version:
3.9.1. Do not have 4.0 handy to test with 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 30562] Selection DAG error: Detected cycle in SelectionDAG
https://bugs.llvm.org/show_bug.cgi?id=30562 Simon Pilgrim changed: What|Removed |Added Version|3.9 |trunk Resolution|--- |FIXED Product|new-bugs|libraries Status|NEW |RESOLVED Component|new bugs|Common Code Generator Code --- Comment #3 from Simon Pilgrim --- Fixed by rL300314 -- 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 32679] [Windows]Clang Coverage attempts to mangle name of not fully instantiated class template function
http://bugs.llvm.org/show_bug.cgi?id=32679 Vedant Kumar changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Vedant Kumar --- Fixed in clang/r300723. -- 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 32708] The shift didn't carry out the value in bit-field structure
https://bugs.llvm.org/show_bug.cgi?id=32708 Eli Friedman changed: What|Removed |Added CC||efrie...@codeaurora.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Eli Friedman --- *** This bug has been marked as a duplicate of bug 17299 *** -- 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 32715] New: Assertion failure: /lib/Analysis/ScopInfo.cpp:797: void polly::MemoryAccess::computeBoundsOnAccessRelation(unsigned int): Assertion `M in.sle(Max) && "Minimum expected to
https://bugs.llvm.org/show_bug.cgi?id=32715 Bug ID: 32715 Summary: Assertion failure: /lib/Analysis/ScopInfo.cpp:797: void polly::MemoryAccess::computeBoundsOnAccessRelation(uns igned int): Assertion `M in.sle(Max) && "Minimum expected to be less or equal than max"' failed. Product: Polly Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Other Assignee: polly-...@googlegroups.com Reporter: sabua...@codeaurora.org CC: llvm-bugs@lists.llvm.org Created attachment 18315 --> https://bugs.llvm.org/attachment.cgi?id=18315&action=edit reduced ll file for the test case This bug causes a crash in ScopInfo with an assertion failure: "opt: lib/Analysis/ScopInfo.cpp:797: void polly::MemoryAccess::computeBoundsOnAccessRelation(unsigned int): Assertion `M in.sle(Max) && "Minimum expected to be less or equal than max"' failed." Reduced IR attached. can recrete the crash with opt -S -O3 -polly -polly-scops -polly-tiling=false -polly-allow-nonaffine -polly-process-unprofitable ./test_case.ll My investigation shows this was introduced by r294891 : Author: Tobias Grosser Date: Sun Feb 12 08:11:12 2017 + Do not use wrapping ranges to bound non-affine accesses -- 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 32710] PMADDWD optimization on unsigned 16 bit integer
https://bugs.llvm.org/show_bug.cgi?id=32710 Dehao Chen changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Dehao Chen --- Resolved in r300737. Thanks for the bug report and analysis and the proposed fix :) -- 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 32177] Bug in APFloat::mod
https://bugs.llvm.org/show_bug.cgi?id=32177 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Simon Pilgrim --- Added test case at rL300750 -- 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 3316] Constant folding for 'frem' is flaky
https://bugs.llvm.org/show_bug.cgi?id=3316 Simon Pilgrim changed: What|Removed |Added CC||llvm-...@redking.me.uk Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Simon Pilgrim --- D29346 was committed at rL299256 Added remaining test from this ticket at rL300757 -- 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 27950] LIBCXXABI_GCC_TOOLCHAIN is not used during configuration
http://bugs.llvm.org/show_bug.cgi?id=27950 Eugene Zelenko changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Eugene Zelenko --- @Eric, I just checked with trunk (r300713), it still doesn't work :-( -- 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 32716] New: LLVM fails to build with GCC 7
https://bugs.llvm.org/show_bug.cgi?id=32716
Bug ID: 32716
Summary: LLVM fails to build with GCC 7
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: Support Libraries
Assignee: unassignedb...@nondot.org
Reporter: ved...@miletic.net
CC: llvm-bugs@lists.llvm.org
[ 35%] Building CXX object lib/Option/CMakeFiles/LLVMOption.dir/Arg.cpp.o
In file included from /home/vedranm/workspace/llvm/lib/Option/Arg.cpp:13:0:
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h: In member function
„llvm::opt::ArgList::iterator llvm::opt::ArgList::begin()”:
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:184:54: greška:
invalid initialization of reference of type „const llvm::opt::OptSpecifier
(&)[1]” from expression of type „const llvm::opt::OptSpecifier [1]”
iterator begin() { return {Args.begin(), Args.end()}; }
^
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:71:3: napomena: in
passing argument 3 of „llvm::opt::arg_iterator::arg_iterator(BaseIter, BaseIter, const
llvm::opt::OptSpecifier (&)[(NumOptSpecifiers ? NumOptSpecifiers : 1)]) [with
BaseIter = llvm::opt::Arg**; unsigned int NumOptSpecifiers = 0]”
arg_iterator(
^~~~
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h: In member function
„llvm::opt::ArgList::iterator llvm::opt::ArgList::end()”:
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:185:50: greška:
invalid initialization of reference of type „const llvm::opt::OptSpecifier
(&)[1]” from expression of type „const llvm::opt::OptSpecifier [1]”
iterator end() { return {Args.end(), Args.end()}; }
^
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:71:3: napomena: in
passing argument 3 of „llvm::opt::arg_iterator::arg_iterator(BaseIter, BaseIter, const
llvm::opt::OptSpecifier (&)[(NumOptSpecifiers ? NumOptSpecifiers : 1)]) [with
BaseIter = llvm::opt::Arg**; unsigned int NumOptSpecifiers = 0]”
arg_iterator(
^~~~
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h: In member function
„llvm::opt::ArgList::reverse_iterator llvm::opt::ArgList::rbegin()”:
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:187:49: greška:
could not convert „llvm::SmallVectorTemplateCommon
>::rbegin() [with T = llvm::opt::Arg*; = void;
llvm::SmallVectorTemplateCommon >::reverse_iterator
= std::reverse_iterator]()” from
„llvm::SmallVectorTemplateCommon::reverse_iterator {aka
std::reverse_iterator}” to
„llvm::opt::ArgList::reverse_iterator {aka
llvm::opt::arg_iterator >}”
reverse_iterator rbegin() { return Args.rbegin(); }
~~~^~
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h: In member function
„llvm::opt::ArgList::reverse_iterator llvm::opt::ArgList::rend()”:
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:188:45: greška:
could not convert „llvm::SmallVectorTemplateCommon
>::rend() [with T = llvm::opt::Arg*; = void;
llvm::SmallVectorTemplateCommon >::reverse_iterator
= std::reverse_iterator]()” from
„llvm::SmallVectorTemplateCommon::reverse_iterator {aka
std::reverse_iterator}” to
„llvm::opt::ArgList::reverse_iterator {aka
llvm::opt::arg_iterator >}”
reverse_iterator rend() { return Args.rend(); }
~^~
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h: In member function
„llvm::opt::ArgList::const_iterator llvm::opt::ArgList::begin() const”:
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:190:51: greška:
could not convert „((const
llvm::opt::ArgList*)this)->llvm::opt::ArgList::Args.llvm::SmallVector::.llvm::SmallVectorImpl::.llvm::SmallVectorTemplateBase::.llvm::SmallVectorTemplateCommon::begin()” from „llvm::SmallVectorTemplateCommon::const_iterator {aka llvm::opt::Arg* const*}” to
„llvm::opt::ArgList::const_iterator {aka
llvm::opt::arg_iterator}”
const_iterator begin() const { return Args.begin(); }
~~^~
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h: In member function
„llvm::opt::ArgList::const_iterator llvm::opt::ArgList::end() const”:
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h:191:47: greška:
could not convert „((const
llvm::opt::ArgList*)this)->llvm::opt::ArgList::Args.llvm::SmallVector::.llvm::SmallVectorImpl::.llvm::SmallVectorTemplateBase::.llvm::SmallVectorTemplateCommon::end()” from „llvm::SmallVectorTemplateCommon::const_iterator {aka llvm::opt::Arg* const*}” to
„llvm::opt::ArgList::const_iterator {aka
llvm::opt::arg_iterator}”
const_iterator end() const { return Args.end(); }
^~
/home/vedranm/workspace/llvm/include/llvm/Option/ArgList.h: In me
[llvm-bugs] [Bug 32382] LLVM may create invalid DWARF 4+ expressions
https://bugs.llvm.org/show_bug.cgi?id=32382 Adrian Prantl changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Adrian Prantl --- This ought to be fixed by r300522: PR32382: Fix emitting complex DWARF expressions. -- 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 32717] New: Merging conflicting profiles fails in the IRMover with a non-friendly diagnostic
https://bugs.llvm.org/show_bug.cgi?id=32717
Bug ID: 32717
Summary: Merging conflicting profiles fails in the IRMover with
a non-friendly diagnostic
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: dav...@freebsd.org
CC: davi...@google.com, era...@google.com,
llvm-bugs@lists.llvm.org, simon.f.whitta...@gmail.com,
x...@google.com
Reduced from a case I hit in the wild.
$ cat adler.ll
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-scei-ps4"
define i64 @tinkywinky() {
ret i64 0
}
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"ProfileSummary", !1}
!1 = !{!2, !3, !4, !5, !6, !7, !8, !9}
!2 = !{!"ProfileFormat", !"InstrProf"}
!3 = !{!"TotalCount", i64 0}
!4 = !{!"MaxCount", i64 0}
!5 = !{!"MaxInternalCount", i64 0}
!6 = !{!"MaxFunctionCount", i64 0}
!7 = !{!"NumCounts", i64 0}
!8 = !{!"NumFunctions", i64 0}
!9 = !{!"DetailedSummary", !10}
!10 = !{!11, !12, !13, !14, !15, !16, !16, !17, !17, !18, !19, !20, !21, !22,
!23, !24, !25, !26}
!11 = !{i32 1, i64 0, i32 0}
!12 = !{i32 10, i64 0, i32 0}
!13 = !{i32 20, i64 0, i32 0}
!14 = !{i32 30, i64 0, i32 0}
!15 = !{i32 40, i64 0, i32 0}
!16 = !{i32 50, i64 0, i32 0}
!17 = !{i32 60, i64 0, i32 0}
!18 = !{i32 70, i64 0, i32 0}
!19 = !{i32 80, i64 0, i32 0}
!20 = !{i32 90, i64 0, i32 0}
!21 = !{i32 95, i64 0, i32 0}
!22 = !{i32 99, i64 0, i32 0}
!23 = !{i32 999000, i64 0, i32 0}
!24 = !{i32 00, i64 0, i32 0}
!25 = !{i32 90, i64 0, i32 0}
!26 = !{i32 99, i64 0, i32 0}
]$ cat main.ll
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-scei-ps4"
define i32 @patatino() {
ret i32 0
}
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"ProfileSummary", !1}
!1 = !{!2, !3, !4, !5, !6, !7, !8, !9}
!2 = !{!"ProfileFormat", !"InstrProf"}
!3 = !{!"TotalCount", i64 105148752377}
!4 = !{!"MaxCount", i64 7107491985}
!5 = !{!"MaxInternalCount", i64 6186825744}
!6 = !{!"MaxFunctionCount", i64 7107491985}
!7 = !{!"NumCounts", i64 128499}
!8 = !{!"NumFunctions", i64 33234}
!9 = !{!"DetailedSummary", !10}
!10 = !{!11, !12, !13, !14, !15, !16, !16, !17, !17, !18, !19, !20, !21, !22,
!23, !24, !25, !26}
!11 = !{i32 1, i64 7107491985, i32 1}
!12 = !{i32 10, i64 6186825744, i32 2}
!13 = !{i32 20, i64 1175154662, i32 7}
!14 = !{i32 30, i64 635580706, i32 20}
!15 = !{i32 40, i64 395565517, i32 42}
!16 = !{i32 50, i64 250826197, i32 75}
!17 = !{i32 60, i64 96522752, i32 150}
!18 = !{i32 70, i64 49363736, i32 311}
!19 = !{i32 80, i64 25985024, i32 599}
!20 = !{i32 90, i64 9803979, i32 1273}
!21 = !{i32 95, i64 4164740, i32 2053}
!22 = !{i32 99, i64 658981, i32 4382}
!23 = !{i32 999000, i64 44010, i32 8841}
!24 = !{i32 00, i64 13789, i32 13065}
!25 = !{i32 90, i64 1913, i32 14489}
!26 = !{i32 99, i64 160, i32 15937}
Script to reproduce (adjusting the paths)
$ cat run.sh
rm -rf main.o adler.o
~/work/llvm/build-clang/bin/llvm-as /home/davide/smbrokenpgo/reduced/main.ll -o
main.o
~/work/llvm/build-clang/bin/llvm-as /home/davide/smbrokenpgo/reduced/adler.ll
-o adler.o
~/work/llvm/build-clang/bin/ld.lld main.o adler.o
--
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 32718] New: lld-created binaries do not end up in disk cache (?)
https://bugs.llvm.org/show_bug.cgi?id=32718
Bug ID: 32718
Summary: lld-created binaries do not end up in disk cache (?)
Product: lld
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: ELF
Assignee: unassignedb...@nondot.org
Reporter: richard-l...@metafoo.co.uk
CC: llvm-bugs@lists.llvm.org
After linking Clang with ld.bfd or ld.gold, if I run the binary, it starts
~instantly. If I instead link with ld.lld, I incur a several second startup
time the first time I run the Clang binary, and 'perf' indicates the time is
spent paging in the binary.
Here's what ld.bfd does to create its output binary (when the output file
already exists):
stat("x", {st_mode=S_IFREG|0750, st_size=1079, ...}) = 0
lstat("x", {st_mode=S_IFREG|0750, st_size=1079, ...}) = 0
unlink("x") = 0
open("x", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
fcntl(3, F_GETFD) = 0
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
fstat(3, {st_mode=S_IFREG|0640, st_size=0, ...}) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, "", 64) = 0
lseek(3, 64, SEEK_CUR) = 64
write(3, "\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0"...,
120) = 120
# ... lots more seeking, reading, and writing on fd 3
write(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
448) = 448
close(3)= 0
stat("x", {st_mode=S_IFREG|0640, st_size=1079, ...}) = 0
umask(0)= 027
umask(027) = 0
chmod("x", 0750)= 0
Here's what ld.gold does:
stat("x", {st_mode=S_IFREG|0750, st_size=1079, ...}) = 0
unlink("x") = 0
open("x", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0777) = 4
fstat(4, {st_mode=S_IFREG|0750, st_size=0, ...}) = 0
fallocate(4, 0, 0, 1072)= 0
mmap(NULL, 1072, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x7fdfec2db000
munmap(0x7fdfec2db000, 1072)= 0
close(4)= 0
Here's what ld.lld does:
access("x", F_OK) = 0
access("xtmp5181559f", F_OK)= -1 ENOENT (No such file or directory)
rename("x", "xtmp5181559f") = 0
stat("x", 0x7ffd9649e180) = -1 ENOENT (No such file or directory)
lstat("x", 0x7ffd9649e220) = -1 ENOENT (No such file or directory)
open("x.tmp3566de2", O_RDWR|O_CREAT|O_EXCL|O_TRUNC|O_CLOEXEC, 0777) = 3
fallocate(3, 0, 0, 4736)= 0
mmap(NULL, 4736, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fd09a5bf000
close(3)= 0
munmap(0x7fd09a5bf000, 4736)= 0
rename("x.tmp3566de2", "x") = 0
There are a few odd things here. Using temporary files (which sometimes get
left behind!) seems unnecessary and error-prone, and stat'ing a file we just
renamed seems pointless. But I suspect the slowness is caused either by the
rename or by the relative order of the close and munmap calls.
--
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 30630] LoopVectorizer generating bad and unhandled shufflevector sequence
http://bugs.llvm.org/show_bug.cgi?id=30630 Jonas Paulsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #13 from Jonas Paulsson --- I beleive there is not an issue any more at least for the moment with shuffles on SystemZ :-) -- 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
