[llvm-bugs] [Bug 31082] New: wrong code from the BB vectorization pass (-bb-vectorize)
https://llvm.org/bugs/show_bug.cgi?id=31082
Bug ID: 31082
Summary: wrong code from the BB vectorization pass
(-bb-vectorize)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ clang -v
clang version 4.0.0 (trunk 287325)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -c -emit-llvm -w -o small.bc small.c
$ opt -bb-vectorize -o small-opt.bc small.bc
$ llc -o small.s small-opt.bc
$ gcc small.s
$ ./a.out
Segmentation fault (core dumped)
$
int a, b, c;
int main ()
{
long d[] = { 1, 1, 0, 1, 1 };
a ^ b ^ (~c - 1L);
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 31083] New: Merge rL287227 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=31083 Bug ID: 31083 Summary: Merge rL287227 into the 3.9 branch Product: OpenMP Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: a.bat...@hotmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I would like to propose merging the change... rL287227 [OPENMP] Fixed codegen for 'omp cancel' construct. If 'omp cancel' construct is used in a worksharing construct it may cause hanging of the software in case if reduction clause is used. Patch fixes this problem by avoiding extra reduction processing for branches that were canceled. to 3.9 branch for the 3.9.1 release -- 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 31084] New: [libcxx] Add C++ library benchmarks
https://llvm.org/bugs/show_bug.cgi?id=31084 Bug ID: 31084 Summary: [libcxx] Add C++ library benchmarks Product: Test Suite Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Programs Tests Assignee: unassignedb...@nondot.org Reporter: renato.go...@linaro.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified We have plenty of C++ library tests in the libcxx repo, but no benchmarks at all. During the "Libcxx performance" BoF at the US LLVM 2016, we discussed that adding such a benchmark to the test-suite would be a great idea. However, I have no idea how to even start. First, there were some talks about integrating the Google Benchmark [1] into the test-suite and (maybe) convert the current benchmarks to use it. Regardless of a potential move, since we're creating a whole new benchmark, I'd assume using a tested tool is better than using gettimeofday()... Second, what kinds of tests do we want? I can think of two approaches: 1. We test the "number of iterations" that algorithms and containers perform on small to medium datasets and make sure they're scaling as documented. I'm not sure how to do that other than instrumenting libcxx and only enabling the instrumentation in the benchmark. Other users can enable this on their own programs, for debug? 2. We test the actual "wall time" on a single core (threading is a separate problem), and make sure that not only we don't regress from past runs, but that the actual time spent *also* scales with the guarantees. What we cannot do is to compare with other standard libraries, unless we want to include their sources (and build) in the test-suite. Relying on whatever is in the system will never work across the board. Finally, the "complicated set". Threading, atomics and localisation tend to be hard to test and heavily dependent on the architecture and OS. We already have tests for that, but I fear the run time of those tests, if measured, will have a large deviation, even on the same architecture/OS combination. Sub-architecture and OS configureations will play a heavy role on them. So, how do we start? Who want's to help? cheers, --renato [1] https://github.com/google/benchmark -- 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 31085] New: AVR Assertion error: Offset is out of range
https://llvm.org/bugs/show_bug.cgi?id=31085 Bug ID: 31085 Summary: AVR Assertion error: Offset is out of range Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Target Description Classes Assignee: unassignedb...@nondot.org Reporter: dylanmcka...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified The generic `CodeGen/Generic/2003-05-28-ManyArgs.ll` test fails on AVR due to an assertion error. Assertion failed: (isUInt<6>(MI.getOperand(1).getImm()) && "Offset is out of range"), function fixStackStores, file /Users/dylan/projects/llvm-project/llvm/lib/Target/AVR/AVRFrameLowering.cpp, line 341. 0 libLLVMSupport.dylib 0x00010b6ac595 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 101 1 libLLVMSupport.dylib 0x00010b6acb19 PrintStackTraceSignalHandler(void*) + 25 2 libLLVMSupport.dylib 0x00010b6a97b9 llvm::sys::RunSignalHandlers() + 425 3 libLLVMSupport.dylib 0x00010b6ace52 SignalHandler(int) + 354 4 libsystem_platform.dylib 0x7fff934bf52a _sigtramp + 26 Stack dump: 0. Program arguments: llc 1. Running pass 'Function Pass Manager' on module ''. 2. Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@main' /Users/dylan/projects/builds/llvm/test/CodeGen/Generic/Output/2003-05-28-ManyArgs.ll.script: line 1: 4396 Abort trap: 6 llc < /Users/dylan/projects/llvm-project/llvm/test/CodeGen/Generic/2003-05-28-ManyArgs.ll -- 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 31086] New: Merge r281975 to 3.9.1
https://llvm.org/bugs/show_bug.cgi?id=31086 Bug ID: 31086 Summary: Merge r281975 to 3.9.1 Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: simon.dar...@imgtec.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This adds the MIPS MSA intrinsics header file msa.h to clang. I'd like to backport this patch as it's necessary for a second patch which fixes some intrinsic 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 31087] New: Merge r284620 to 3.9.1
https://llvm.org/bugs/show_bug.cgi?id=31087 Bug ID: 31087 Summary: Merge r284620 to 3.9.1 Product: new-bugs Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: simon.dar...@imgtec.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified This patch adds necessary range checking to the usage of MSA intrinsics, preventing LLVM crashes when parameters to MSA intrinsics are out of range. -- 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 31088] New: Segfault in SelectionDAG for <1 x half>
https://llvm.org/bugs/show_bug.cgi?id=31088
Bug ID: 31088
Summary: Segfault in SelectionDAG for <1 x half>
Product: libraries
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: jonathanchesterfi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Example input:
define <1 x half> @ir_fadd_v1f16(<1 x half> %arg0, <1 x half> %arg1) {
%retval = fadd <1 x half> %arg0, %arg1
ret <1 x half> %retval
}
llc -version
LLVM version 3.9.1
Optimised build.
Default target: x86_64-unknown-linux-gnu
llc tmp.ll
#0 0x014a9995 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/local/bin/llc+0x14a9995)
#1 0x014aa006 SignalHandler(int) (/usr/local/bin/llc+0x14aa006)
#2 0x7f975eb1c8d0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0xf8d0)
#3 0x013836ea llvm::SelectionDAG::getNode(unsigned int, llvm::SDLoc
const&, llvm::EVT, llvm::SDValue) (/usr/local/bin/llc+0x13836ea)
#4 0x0141e46a
llvm::DAGTypeLegalizer::PromoteFloatRes_UnaryOp(llvm::SDNode*)
(/usr/local/bin/llc+0x141e46a)
#5 0x0141d97e llvm::DAGTypeLegalizer::PromoteFloatResult(llvm::SDNode*,
unsigned int) (/usr/local/bin/llc+0x141d97e)
#6 0x013e83ff llvm::DAGTypeLegalizer::run()
(/usr/local/bin/llc+0x13e83ff)
#7 0x013ed336 llvm::SelectionDAG::LegalizeTypes()
(/usr/local/bin/llc+0x13ed336)
#8 0x013b44b5 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/usr/local/bin/llc+0x13b44b5)
#9 0x013b426f
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/usr/local/bin/llc+0x13b426f)
#10 0x013b1bdc
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/usr/local/bin/llc+0x13b1bdc)
#11 0x00cb4541 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/usr/local/bin/llc+0xcb4541)
#12 0x00fb5ccb
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/local/bin/llc+0xfb5ccb)
#13 0x011843af llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/local/bin/llc+0x11843af)
#14 0x0118459b llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/local/bin/llc+0x118459b)
#15 0x01184997 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/bin/llc+0x1184997)
#16 0x0063be5a compileModule(char**, llvm::LLVMContext&)
(/usr/local/bin/llc+0x63be5a)
#17 0x0063966b main (/usr/local/bin/llc+0x63966b)
#18 0x7f975d92bb45 __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b45)
#19 0x00638953 _start (/usr/local/bin/llc+0x638953)
Stack dump:
0. Program arguments: /usr/local/bin/llc tmp.ll
1. Running pass 'Function Pass Manager' on module 'tmp.ll'.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function
'@ir_fadd_v1f16'
Segmentation fault
I've checked similar functions and they're fine - half, <2 x half>, <1 x
float>, float are OK. I haven't checked whether this reproduces on trunk.
Expected behaviour was no segfault, codegen broadly equivalent to a scalar
half.
Cheers
--
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 31089] New: [ELF] 0 LLD seems handles input format binary wrong.
https://llvm.org/bugs/show_bug.cgi?id=31089 Bug ID: 31089 Summary: [ELF] 0 LLD seems handles input format binary wrong. Product: lld Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: gri...@accesssoftek.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Created attachment 17622 --> https://llvm.org/bugs/attachment.cgi?id=17622&action=edit cpio Faced this when tried to link FreeBSD kerned using lld. ===> drm2/radeonkmsfw/ARUBA_me (all) ARUBA_me.bin ARUBA_me.bin /root/Desktop/LLVM/build/bin/ld.lld: error: target emulation unknown: -m or at least one .o file required *** Error code 1 Reproduce file has next lines: --format=binary --no-warn-mismatch --define-common -warn-common --relocatable --define-common -o ARUBA_me.bin.fwo usr/obj/usr/src/sys/CUSTOM/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin ld links fine, lld shows an error. -- You are receiving this mail because: You are on the CC list for the bug. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 30992] AVX512: _mm_loadu_ps alignment issue
https://llvm.org/bugs/show_bug.cgi?id=30992 michael changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from michael --- The bug was a typo mistake. Committed to D287531. Index: lib/Target/X86/X86InstrInfo.cpp === --- lib/Target/X86/X86InstrInfo.cpp(revision 287531) +++ lib/Target/X86/X86InstrInfo.cpp(revision 287532) @@ -5134,7 +5134,7 @@ else return load ? (HasVLX? X86::VMOVUPSZ128rm : - HasAVX512 ? X86::VMOVAPSZ128rm_NOVLX : + HasAVX512 ? X86::VMOVUPSZ128rm_NOVLX : HasAVX? X86::VMOVUPSrm : X86::MOVUPSrm): (HasVLX? X86::VMOVUPSZ128mr : -- 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 31090] New: [LV] Usage of runtime scev checks in the loop vectorizer can be improved
https://llvm.org/bugs/show_bug.cgi?id=31090 Bug ID: 31090 Summary: [LV] Usage of runtime scev checks in the loop vectorizer can be improved Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: opt Assignee: unassignedb...@nondot.org Reporter: dorit.nuz...@intel.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Three improvements to the way loop vectorizer uses scev runtime checks, which were surfaced by D25276: 1) scev runtime checks are currently not used by the interleaved-memory-accesses analysis, which makes it too conservative: Currently we use Assume=false in the call to getPtrStride when we check for possible pointer wrap-around in analyzeInterleaving(). We could use Assume=true instead, however we need to do that with care because adding these possibly "nice to have" runtime checks (loop may be vectorized without interleaving) might prevent us from adding necessary runtime checks later (due to exceeding the SCEV-runtime-checks-threshold) thereby preventing vectorization altogether. We should take into account the maximum number of checks allowed, and make sure that we don't exceed it. Two of the testcases added by D25276/r285568 require Assume=true in order to prove that the stride is 2 (so these represent missed optimization and will not be vectorized until this item is addressed). 2) Still in the context if interleaved-mem-access analysis: Once we allow the scev runtime checks, we could also try to minimize the need to create them: As noted by Silviu: “If we are peeling the loop and we know that the first pointer doesn't wrap then we can deduce that all pointers in the group don't wrap. This means that we can forcefully peel the loop in order to only have to check the first pointer for no-wrap. When we'll change to use Assume=true,ShouldCheckWrap=true we'll only need at most one runtime check per interleaved group (I think this is probably optimal).” 3) Lastly (unrelated to interleaved-access-analysis): We have a problem in the vectorizer of potentially adding runtime SCEV assumptions without ever checking if we exceed the threshold: getPtrStride is called with Assume=true several times from the cost-model stage and from the actual vectorization transformation stage, via the call to isConsecutivePtr. These call sites are past the point when we check whether we exceeded the threshold for runtime SCEV assumptions... Some suggestions that were raised by Silviu: “ - allow Predicated Scalar Evolution interface to only add these checks if we don't exceed a certain threshold - I've found that we can often rewrite the code to only add these checks if we really need them - while we shouldn't be adding new predicates in the transformation stage, in this case we are adding predicates that will always be useful (we should get better codegen for AddRecExprs). Maybe the best solution would be to try to make all pointers AddRecExprs in the legality stage for 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 31089] [ELF] - LLD seems handles input format binary wrong.
https://llvm.org/bugs/show_bug.cgi?id=31089 George Rimar changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #7 from George Rimar --- After switch to svn://svn.freebsd.org/base/head/ I can confirm this gone for me. So we can reopen it later if will want. -- 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 31091] New: libunwind: [ARM] EHABI getInfoFromEHABISection can fail if last .ARM.exidx table entry contains unwind information
https://llvm.org/bugs/show_bug.cgi?id=31091
Bug ID: 31091
Summary: libunwind: [ARM] EHABI getInfoFromEHABISection can
fail if last .ARM.exidx table entry contains unwind
information
Product: libc++abi
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedb...@nondot.org
Reporter: peter.sm...@linaro.org
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Classification: Unclassified
If the last entry of the .ARM.exidx table contains unwinding information
libunwind will be unable to find it.
I have been testing out lld's ARM port against the libcxxabi tests and found a
few exceptions test failures. These failures would disappear if I reordered the
functions so that no function that threw and caught an exception was after
main.
I tracked the point of failure down to getInfoFromEHABISection:
template
bool UnwindCursor::getInfoFromEHABISection(
pint_t pc,
const UnwindInfoSections §s) {
EHABISectionIterator begin =
EHABISectionIterator::begin(_addressSpace, sects);
EHABISectionIterator end =
EHABISectionIterator::end(_addressSpace, sects);
EHABISectionIterator itNextPC = std::upper_bound(begin, end, pc);
if (itNextPC == begin || itNextPC == end)
return false;
EHABISectionIterator itThisPC = itNextPC - 1;
pint_t thisPC = itThisPC.functionAddress();
pint_t nextPC = itNextPC.functionAddress();
pint_t indexDataAddr = itThisPC.dataAddress();
If the last entry in the table contains the pc then upper_bound will return end
and return false. When I reorder the table entries main is last and the tests
don't throw through main so all thrown exceptions are caught as expected.
It turns out that ld.bfd inserts a sentinel EXIDX_CANTUNWIND .ARM.exidx entry
as the last entry in the table (usually the address of rodata is used) which
means that this implementation will always work when ld.bfd is used.
A sentinel entry is useful as without it the scope of the last table entry is
the start of the program to the end of the address space (unless some other
information from the runtime is used to find the highest acceptable PC).
However I cannot find anywhere within the EHABI specification
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf
that requires the presence of a sentinel entry. Unless I've missed something I
think that the libunwind implementation isn't compliant with the specification.
As ld.bfd always adds a terminating table entry this can't be reproduced with
it.
I used the lld ARM port using libcxx libcxxabi and libunwind running
catch_pointer_nullptr.pass.cpp (the templated tests are generated after main).
It may be possible, even beneficial to get lld to add a sentinel terminating
table entry in the same way, however I think it is still worth raising this as
there are other third party linkers that may use libunwind and won't
necessarily add a sentinel.
--
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 31092] New: clang-format Emacs integration breaks on Windows
https://llvm.org/bugs/show_bug.cgi?id=31092 Bug ID: 31092 Summary: clang-format Emacs integration breaks on Windows Product: clang Version: 3.9 Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: rom...@alazartech.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified Running `clang-format-buffer` from clang-format.el on any file that contains multiple lines under Windows throws an error, even if the file contains only ASCII characters: (clang-format failed with code 1: error: invalid length 34, offset + length (34) is outside the file.) The issues comes from the fact that Emacs uses `undecided-unix` encoding by default to send data to subprocesses, but `undecided-dos` to receive data from them, as shown by calling `describe-coding-system` on any buffer. This problem can be fixed by calling `(setq default-process-coding-system '(undecided-dos . undecided-dos))` in `.emacs`. I am not sure if this issue can or should be solved at clang-format.el level, but I thought it is worth pointing out since it affects every Emacs user on Windows that hasn't fiddled with the `default-process-coding-system` variable. -- 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 31093] New: Crash at code completion involving overloaded and static function
https://llvm.org/bugs/show_bug.cgi?id=31093
Bug ID: 31093
Summary: Crash at code completion involving overloaded and
static function
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: libclang
Assignee: unassignedclangb...@nondot.org
Reporter: nikolai.kos...@qt.io
CC: kli...@google.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat source.cpp
struct Foo {
void foo() const;
static void foo(bool);
};
struct Bar
{
void foo(bool param)
{
Foo::foo(pa/*COMPLETE HERE*/)
}
};
$ c-index-test -code-completion-at=source.cpp:10:18 source.cpp
libclang: crash detected in code completion
Unable to perform code completion!
--
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 31094] New: template parameter not deducible in partial specialization of template inside template
https://llvm.org/bugs/show_bug.cgi?id=31094
Bug ID: 31094
Summary: template parameter not deducible in partial
specialization of template inside template
Product: clang
Version: 3.9
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: akond...@kcg.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Classification: Unclassified
The code below worked on clang 3.6, but warns on 3.8 and 3.9:
template
struct outer
{
template
struct inner
{
};
};
template
struct is_inner_for
{
template
struct predicate
{
static constexpr bool value = false;
};
template
struct predicate::template inner>
{
static constexpr bool value = true;
};
};
static_assert(
is_inner_for::template predicate<
outer::inner
>::value,
"Yay!"
);
Here is the warning:
:23:12: warning: class template partial specialization contains a
template parameter that cannot be deduced; this partial specialization will
never be used
struct predicate::template inner>
^~~
:22:24: note: non-deducible template parameter 'U'
template
^
1 warning generated.
Even though clang warns about the partial specialization not being used, the
code compiles fine and that specialization is in fact used.
GCC 6 bug that resulted in the same type of error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70141
Godbolt output: https://godbolt.org/g/pqJcQu
Stack overflow question:
http://stackoverflow.com/questions/35875829/template-parameters-not-deducible-in-partial-specialization-in-gcc6-for-a-case
--
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 31095] New: During loop-deletion: Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed.
https://llvm.org/bugs/show_bug.cgi?id=31095
Bug ID: 31095
Summary: During loop-deletion: Assertion `use_empty() && "Uses
remain when a value is destroyed!"' failed.
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: bjorn.a.petters...@ericsson.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
An assert was triggered when compiling a test case generated using csmith.
The test case has been reduced to this:
define void @main() {
entry:
br label %main_loop
main_loop:
br i1 undef, label %if_target, label %else_target
if_target:
%tmp = add i32 undef, -1
br label %main_loop
else_target:
unreachable
disconnected_loop:
call void @dummy_func(i32 %tmp)
br label %disconnected_loop
}
Can be reproduced by running
opt -S -loop-deletion
with the above code as input.
Output with stack trace using a debug build:
While deleting: i32 %tmp
Use still stuck around after Def is destroyed: call void @dummy_func(i32 %tmp)
opt: ../lib/IR/Value.cpp:85: virtual llvm::Value::~Value(): Assertion
`use_empty() && "Uses remain when a value is destroyed!"' failed.
#0 0x02b381bf llvm::sys::PrintStackTrace(llvm::raw_ostream&)
lib/Support/Unix/Signals.inc:402:5
#1 0x02b386c9 PrintStackTraceSignalHandler(void*)
lib/Support/Unix/Signals.inc:466:1
#2 0x02b369b3 llvm::sys::RunSignalHandlers()
lib/Support/Signals.cpp:45:5
#3 0x02b38d0e SignalHandler(int) lib/Support/Unix/Signals.inc:256:1
#4 0x7f54d6809810 __restore_rt (/lib64/libpthread.so.0+0xf810)
#5 0x7f54d59b6755 __GI_raise (/lib64/libc.so.6+0x32755)
#6 0x7f54d59b7d31 __GI_abort (/lib64/libc.so.6+0x33d31)
#7 0x7f54d59af610 __GI___assert_fail (/lib64/libc.so.6+0x2b610)
#8 0x024b02e6 llvm::Value::~Value() lib/IR/Value.cpp:89:3
#9 0x0232eb15 llvm::User::~User() include/llvm/IR/User.h:91:3
#10 0x023ee653 llvm::Instruction::~Instruction()
lib/IR/Instruction.cpp:51:1
#11 0x02409bb5 llvm::BinaryOperator::~BinaryOperator()
include/llvm/IR/InstrTypes.h:328:7
#12 0x02409bd9 llvm::BinaryOperator::~BinaryOperator()
include/llvm/IR/InstrTypes.h:328:7
#13 0x021da8fe
llvm::ilist_alloc_traits::deleteNode(llvm::Instruction*)
include/llvm/ADT/ilist.h:44:49
#14 0x021da8b8 llvm::iplist_impl,
llvm::SymbolTableListTraits
>::erase(llvm::ilist_iterator, false, false>) include/llvm/ADT/ilist.h:283:5
#15 0x0230949b llvm::iplist_impl,
llvm::SymbolTableListTraits
>::erase(llvm::ilist_iterator, false, false>,
llvm::ilist_iterator, false, false>) include/llvm/ADT/ilist.h:320:15
#16 0x023083d4 llvm::iplist_impl,
llvm::SymbolTableListTraits >::clear()
include/llvm/ADT/ilist.h:324:18
#17 0x02306775 llvm::BasicBlock::~BasicBlock()
lib/IR/BasicBlock.cpp:86:1
#18 0x02306839 llvm::BasicBlock::~BasicBlock()
lib/IR/BasicBlock.cpp:64:27
#19 0x0230928e
llvm::ilist_alloc_traits::deleteNode(llvm::BasicBlock*)
include/llvm/ADT/ilist.h:44:49
#20 0x02308658 llvm::iplist_impl,
llvm::SymbolTableListTraits
>::erase(llvm::ilist_iterator, false, false>) include/llvm/ADT/ilist.h:283:5
#21 0x02306926 llvm::BasicBlock::eraseFromParent()
lib/IR/BasicBlock.cpp:98:10
#22 0x028c8b65 llvm::LoopDeletionPass::runImpl(llvm::Loop*,
llvm::DominatorTree&, llvm::ScalarEvolution&, llvm::LoopInfo&)
lib/Transforms/Scalar/LoopDeletion.cpp:199:5
#23 0x028c96d3 (anonymous
namespace)::LoopDeletionLegacyPass::runOnLoop(llvm::Loop*,
llvm::LPPassManager&) lib/Transforms/Scalar/LoopDeletion.cpp:268:3
#24 0x01d364ea llvm::LPPassManager::runOnFunction(llvm::Function&)
lib/Analysis/LoopPass.cpp:201:20
#25 0x02431abd llvm::FPPassManager::runOnFunction(llvm::Function&)
lib/IR/LegacyPassManager.cpp:1511:23
#26 0x02431df5 llvm::FPPassManager::runOnModule(llvm::Module&)
lib/IR/LegacyPassManager.cpp:1532:16
#27 0x024325de (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
lib/IR/LegacyPassManager.cpp:1588:23
#28 0x024320db llvm::legacy::PassManagerImpl::run(llvm::Module&)
lib/IR/LegacyPassManager.cpp:1691:16
#29 0x02432b21 llvm::legacy::PassManager::run(llvm::Module&)
lib/IR/LegacyPassManager.cpp:1722:3
#30 0x00a47f9f main tools/opt/opt.cpp:724:3
#31 0x7f54d59a2c16 __libc_start_main (/lib64/libc.so.6+0x1ec16)
#32 0x00a28895 _start
/usr/src/packages/BUILD/glibc-2.11.3/csu/../sysdeps/x86_64/elf/start.S:116: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 31096] New: Multi-level pointers not disambiguated, even with strict aliasing
https://llvm.org/bugs/show_bug.cgi?id=31096
Bug ID: 31096
Summary: Multi-level pointers not disambiguated, even with
strict aliasing
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: dber...@dberlin.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
The following simple example:
int *p;
int foo(int argc, char **argv)
{
int result;
*p = 2;
if (argc)
*p = 2;
result = *p;
return result;
}
Does not get optimized by GVN (or NewGVN).
It's trivial friend:
int foo(int argc, char **argv, int *p)
{
int result;
*p = 2;
if (argc)
*p = 2;
result = *p;
return result;
}
Does get optimized by NewGVN with a patch i have.
The difference is that the global object turns into an i32 ** that we do a load
from, so the llvm IR looks like this:
@p = common global i32* null, align 8
; Function Attrs: norecurse nounwind ssp uwtable
define i32 @foo(i32, i8** nocapture readnone) #0 {
%3 = load i32*, i32** @p, align 8, !tbaa !2
store i32 2, i32* %3, align 4, !tbaa !6
%4 = icmp eq i32 %0, 0
br i1 %4, label %7, label %5
; :5 ; preds = %2
%6 = load i32*, i32** @p, align 8, !tbaa !2
store i32 2, i32* %6, align 4, !tbaa !6
br label %7
; :7 ; preds = %2, %5
%8 = load i32*, i32** @p, align 8, !tbaa !2
%9 = load i32, i32* %8, align 4, !tbaa !6
ret i32 %9
}
!0 = !{i32 1, !"PIC Level", i32 2}
!1 = !{!"Apple LLVM version 8.0.0 (clang-800.0.42.1)"}
!2 = !{!3, !3, i64 0}
!3 = !{!"any pointer", !4, i64 0}
!4 = !{!"omnipotent char", !5, i64 0}
!5 = !{!"Simple C/C++ TBAA"}
!6 = !{!7, !7, i64 0}
!7 = !{!"int", !4, i64 0}
Note that in this two level version, we believe the stores to i32* can affect
an i32**.
At the "llvm level" this is correct (IE there are no real types, aso we can't
say anything) , however, with strict aliasing, and the original code, it's not
possible.
In fact, at least for basic types, with strict aliasing, it's not possible for
a pointer of level n to affect a pointer of level n+1 (IE a store to an int *
can't ever alias an int **, only the reverse) , but we haven't taught LLVM
that.
(I suspect, btw, the above can be reproduced with multi-level pointers in
general)
Not sure where we should fix this, suggestions welcome.
--
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 31097] New: Merge r279930 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=31097 Bug ID: 31097 Summary: Merge r279930 into the 3.9 branch Product: libraries Version: 3.9 Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: Loop Optimizer Assignee: unassignedb...@nondot.org Reporter: e...@vangyzen.net CC: elena.demikhov...@intel.com, llvm-bugs@lists.llvm.org, tstel...@gmail.com Blocks: 30261 Classification: Unclassified I'd like to nominate r279930 for the 3.9 branch. http://llvm.org/viewvc/llvm-project?view=revision&revision=279930 We ran into this on 3.9.0 (and then confirmed that it affects 3.7.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 31098] New: [LV][MemDeps][SCEV] Unable to prove that a dependence-distance is larger than the trip count
https://llvm.org/bugs/show_bug.cgi?id=31098
Bug ID: 31098
Summary: [LV][MemDeps][SCEV] Unable to prove that a
dependence-distance is larger than the trip count
Product: tools
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: opt
Assignee: unassignedb...@nondot.org
Reporter: dorit.nuz...@intel.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider the following example:
#include
class Complex {
private:
float real_;
float imaginary_;
…
};
void test(Complex *out, size_t size) {
size_t D = size / 2;
for (size_t offset = 0; offset < D; ++ offset)
{
… = out[offset];
… = out[offset + D];
out[offset] = …;
out[offset + D] = …;
}
}
In the above example, memory-dependence analysis fails to prove that an unknown
dependence distance 2*D (+/- 1) is larger than the loop trip count D. This is
because proving this property requires a bit of extra information, information
that the loop-vectorizer has: The vectorizer knows that if execution will enter
the vectorized loop then it must hold that the original trip-count is at least
equal to the selected Vectorization Factor (VF). Otherwise, either only the
scalar peel loop will get executed, or we skip both the vector and remainder
loops altogether. While we don’t know during legality analysis what the
selected VF will end up being, we do know that if the loop is vectorized it
will be at least 2. Just using this bit of information can help us resolve
things in the example in question:
- In the example the dependence-distances (dd) in bytes are:
8*D , 8*D + 4, and 8*D - 4;
The size of the elements is 4 bytes;
The loop backEdgeTakenCount is D-1;
In Dependence analysis we are trying to prove that:
abs(dd) > takenCount * 4:
So in our case we are trying to see if:
abs(8*D – 4) > 4D – 4
abs(8*D) > 4D – 4
abs(8*D + 4) > 4D – 4
Without further information on D we can’t prove the above;
We can’t even prove that dd isKnownNonNegative (to compute the abs).
- Knowing that the loopCount >= VF (as explained above), and assuming
conservatively a VF=2, gives us that:
D >= 2. With that we can prove everything we need.
So in summary, when we get an unknown distance, we don’t have to resort to
runtime tests, we can retry the prove the SCEV equations by providing a bit of
context to the SCEV tools. (Just need to figure out what's the best way to do
that...).
Thanks,
Dorit
--
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 31099] New: wrong code by the LoadCombine pass (-load-combine)
https://llvm.org/bugs/show_bug.cgi?id=31099
Bug ID: 31099
Summary: wrong code by the LoadCombine pass (-load-combine)
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
It seems to a regression from 3.7.x.
$ clang -v
clang version 4.0.0 (trunk 287325)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -c -emit-llvm -w -o small.bc small.c
$
$ llc -o small.s small.bc
$ gcc small.s
$ ./a.out
1
$
$ opt -load-combine -o small-opt.bc small.bc
$ llc -o small-opt.s small-opt.bc
$ gcc small-opt.s
$ ./a.out
0
$
--
int printf (const char *, ...);
struct S
{
int f0;
int f1;
};
int main ()
{
struct S a;
a.f0;
a.f1 = 1;
printf ("%d\n", a.f1);
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 30882] Merge r285283 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30882 Johnny Peyton changed: What|Removed |Added Status|NEW |RESOLVED CC||jpeyto...@gmail.com Resolution|--- |FIXED --- Comment #6 from Johnny Peyton --- Merged into 3.9 branch. -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30882, which changed state. Bug 30882 Summary: Merge r285283 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30882 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 30884] Merge r280138 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30884 Johnny Peyton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Johnny Peyton --- Merged into 3.9 branch. -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30884, which changed state. Bug 30884 Summary: Merge r280138 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30884 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 30883] Merge r285703 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30883 Johnny Peyton changed: What|Removed |Added Status|NEW |RESOLVED CC||jpeyto...@gmail.com Resolution|--- |FIXED --- Comment #6 from Johnny Peyton --- Merged into 3.9 branch -- 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 30881] Merge r278332 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30881 Johnny Peyton changed: What|Removed |Added Status|NEW |RESOLVED CC||jpeyto...@gmail.com Resolution|--- |FIXED --- Comment #6 from Johnny Peyton --- Merged into 3.9 branch -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30881, which changed state. Bug 30881 Summary: Merge r278332 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30881 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30883, which changed state. Bug 30883 Summary: Merge r285703 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30883 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 31100] New: lld implements its own ThreadPool (but shouldn't)
https://llvm.org/bugs/show_bug.cgi?id=31100 Bug ID: 31100 Summary: lld implements its own ThreadPool (but shouldn't) Product: lld Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified We have two implementations of ThreadPool. One in Support/, used for ThinLTO. The other on in lld/Core/Parallel.h, used by all the three backends (COFF/MachO/ELF) for parallel_for_each() and parallel_sort. These two implementations could be merged. As a follow-up, the parallel* utilities in lld could be moved to LLVM, maybe. -- 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 31101] New: Unify LLI and C-API ORC stacks.
https://llvm.org/bugs/show_bug.cgi?id=31101 Bug ID: 31101 Summary: Unify LLI and C-API ORC stacks. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: lha...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified LLI and the ORC C-bindings each have their own stack, but they have a lot of overlapping functionality. They should almost certainly share a single stack, which could also be made directly available to LLVM clients who want to use 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 31102] New: Merge r280990 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=31102 Bug ID: 31102 Summary: Merge r280990 into the 3.9 branch Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: e...@vangyzen.net CC: dav...@freebsd.org, llvm-bugs@lists.llvm.org, tstel...@gmail.com Depends on: 30330 Blocks: 30261 Classification: Unclassified Please merge lld r280990 to the 3.9 branch. It fixes bug 30330. We're currently using lld 3.9.0 in production with this one patch. It would be nice to use 3.9.1 out-of-the-box. -- 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 30840] Merge r285254 and r285525 into the 3.9 branch
https://llvm.org/bugs/show_bug.cgi?id=30840 Mehdi Amini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Mehdi Amini --- r287579 and r287580 -- 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 30261] [Meta] 3.9.1 Merges and Bug Fixes
https://llvm.org/bugs/show_bug.cgi?id=30261 Bug 30261 depends on bug 30840, which changed state. Bug 30840 Summary: Merge r285254 and r285525 into the 3.9 branch https://llvm.org/bugs/show_bug.cgi?id=30840 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 31103] New: Design an ORC C-API / ExecutionEngine replacement
https://llvm.org/bugs/show_bug.cgi?id=31103 Bug ID: 31103 Summary: Design an ORC C-API / ExecutionEngine replacement Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: lha...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified Along with http://llvm.org/PR31101 (unifying the existing in-tree ORC stacks) we should design a new C API for ORC. It may make sense to design a replacement for the C++ ExecutionEngine API alongside this. I expect the default JIT implementation for any new interface would be provided by the unified stack developed for http://llvm.org/PR31101, and it may be worth designing the new stack with the interface in mind. There is an existing ORC C-API (see http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm-c/OrcBindings.h) that may serve as a starting point, but it's missing some key features (especially support for remote JITing). A few of important questions off the top of my head: (1) How should resource ownership (Modules, object files, etc) be modeled in the C-API? http://llvm.org/PR30896 will significantly influence this by locking ORC to a shared ownership model. (2) How should remote JITing be handled? (3) How should this interface interact with the LLVM IR interpreter (if at all?) Thoughts from existing clients would be most welcome. -- 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 31104] New: Standalone LLDB build is broken because gtest is defined twice
https://llvm.org/bugs/show_bug.cgi?id=31104 Bug ID: 31104 Summary: Standalone LLDB build is broken because gtest is defined twice Product: Build scripts Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: eugene.zele...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I encountered next problem when tried to build standalone LLDB: CMake Error at pass2.build/lib64/cmake/llvm/AddLLVM.cmake:422 (add_library): add_library cannot create target "gtest" because an imported target with the same name already exists. Call Stack (most recent call first): pass2.build/lib64/cmake/llvm/AddLLVM.cmake:560 (llvm_add_library) llvm-svn.src/utils/unittest/CMakeLists.txt:40 (add_llvm_library) CMake Error at pass2.build/lib64/cmake/llvm/AddLLVM.cmake:531 (target_link_libraries): Cannot specify link libraries for target "gtest" which is not built by this project. Call Stack (most recent call first): pass2.build/lib64/cmake/llvm/AddLLVM.cmake:560 (llvm_add_library) llvm-svn.src/utils/unittest/CMakeLists.txt:40 (add_llvm_library) First time gtest is defined in: pass2.build/lib64/cmake/llvm/LLVMBuildTreeOnlyTargets.cmake(42): add_library(gtest STATIC IMPORTED ) -- 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 31105] New: crash on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (Assertion `!contains(New, this) && "this->replaceAllUsesWith(expr(this)) is NOT valid!"' failed.)
https://llvm.org/bugs/show_bug.cgi?id=31105 Bug ID: 31105 Summary: crash on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes (Assertion `!contains(New, this) && "this->replaceAllUsesWith(expr(this)) is NOT valid!"' failed.) Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: chengnian...@gmail.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified $ clang-trunk -v clang version 4.0.0 (trunk 287553) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clang-trunk -w -O3 small.c clang-4.0: /tmp/llvm-builder/llvm-source-trunk/lib/IR/Value.cpp:373: void llvm::Value::replaceAllUsesWith(llvm::Value*): Assertion `!contains(New, this) && "this->replaceAllUsesWith(expr(this)) is NOT valid!"' failed. #0 0x01d194a5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/clang-trunk/bin/clang-4.0+0x1d194a5) #1 0x01d1747e llvm::sys::RunSignalHandlers() (/usr/local/clang-trunk/bin/clang-4.0+0x1d1747e) #2 0x01d175e2 SignalHandler(int) (/usr/local/clang-trunk/bin/clang-4.0+0x1d175e2) #3 0x7f5af316a340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x7f5af1f5bcc9 gsignal /build/eglibc-3GlaMS/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 #5 0x7f5af1f5f0d8 abort /build/eglibc-3GlaMS/eglibc-2.19/stdlib/abort.c:91:0 #6 0x7f5af1f54b86 __assert_fail_base /build/eglibc-3GlaMS/eglibc-2.19/assert/assert.c:92:0 #7 0x7f5af1f54c32 (/lib/x86_64-linux-gnu/libc.so.6+0x2fc32) #8 0x019b7d8b llvm::Value::replaceAllUsesWith(llvm::Value*) (/usr/local/clang-trunk/bin/clang-4.0+0x19b7d8b) #9 0x01d3ef72 llvm::CloneAndPruneIntoFromInst(llvm::Function*, llvm::Function const*, llvm::Instruction const*, llvm::ValueMap > >&, bool, llvm::SmallVectorImpl&, char const*, llvm::ClonedCodeInfo*) (/usr/local/clang-trunk/bin/clang-4.0+0x1d3ef72) #10 0x01d5d883 llvm::InlineFunction(llvm::CallSite, llvm::InlineFunctionInfo&, llvm::AAResults*, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x1d5d883) #11 0x01a0a083 llvm::Inliner::inlineCalls(llvm::CallGraphSCC&) (/usr/local/clang-trunk/bin/clang-4.0+0x1a0a083) #12 0x0263a912 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x263a912) #13 0x019826af llvm::legacy::PassManagerImpl::run(llvm::Module&) (/usr/local/clang-trunk/bin/clang-4.0+0x19826af) #14 0x01e844bf (anonymous namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x1e844bf) #15 0x01e86335 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr >) (/usr/local/clang-trunk/bin/clang-4.0+0x1e86335) #16 0x024a9f1b clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/usr/local/clang-trunk/bin/clang-4.0+0x24a9f1b) #17 0x0289f102 clang::ParseAST(clang::Sema&, bool, bool) (/usr/local/clang-trunk/bin/clang-4.0+0x289f102) #18 0x024a50ef clang::CodeGenAction::ExecuteAction() (/usr/local/clang-trunk/bin/clang-4.0+0x24a50ef) #19 0x021b48a6 clang::FrontendAction::Execute() (/usr/local/clang-trunk/bin/clang-4.0+0x21b48a6) #20 0x
[llvm-bugs] [Bug 31106] New: opt crashes while running "CallGraph Pass Manager": Assertion `CallSites.empty() && "Dangling pointers found in call sites map"' failed
https://llvm.org/bugs/show_bug.cgi?id=31106
Bug ID: 31106
Summary: opt crashes while running "CallGraph Pass Manager":
Assertion `CallSites.empty() && "Dangling pointers
found in call sites map"' failed
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ clang -v
clang version 4.0.0 (trunk 287325)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -c -emit-llvm -o small.bc small.c
$ opt -inline -loop-extract -o small-opt.bc small.bc
opt: /tmp/llvm-builder/llvm-source-trunk/lib/Analysis/CallGraphSCCPass.cpp:352:
bool {anonymous}::CGPassManager::RefreshCallGraph(const llvm::CallGraphSCC&,
llvm::CallGraph&, bool): Assertion `CallSites.empty() && "Dangling pointers
found in call sites map"' failed.
#0 0x01c3af05 (opt+0x1c3af05)
#1 0x01c38fee (opt+0x1c38fee)
#2 0x01c39150 (opt+0x1c39150)
#3 0x7febf8f5e330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#4 0x7febf7d4ac37 gsignal
/build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#5 0x7febf7d4e028 abort
/build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:91:0
#6 0x7febf7d43bf6 __assert_fail_base
/build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92:0
#7 0x7febf7d43ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#8 0x012b0fd0 (opt+0x12b0fd0)
#9 0x012b1a7b (opt+0x12b1a7b)
#10 0x017d990a (opt+0x17d990a)
#11 0x0078a6b1 (opt+0x78a6b1)
#12 0x7febf7d35f45 __libc_start_main
/build/eglibc-oGUzwX/eglibc-2.19/csu/libc-start.c:321:0
#13 0x007e4336 (opt+0x7e4336)
Stack dump:
0. Program arguments: opt -inline -loop-extract -o small-opt.bc small.bc
1. Running pass 'CallGraph Pass Manager' on module 'small.bc'.
Aborted (core dumped)
$
-
int printf (const char *, ...);
int a;
void fn1 ()
{
while (1)
if (a < 1)
break;
}
int main ()
{
fn1 ();
while (a)
printf ("%d\n", a);
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 31049] [MS] Clang passes small objects with implicitly deleted copy constructors incorrectly on x64
https://llvm.org/bugs/show_bug.cgi?id=31049 Peter Collingbourne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Peter Collingbourne --- Fixed by r287600. -- 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 31107] New: wrong code with "opt -inline -instrprof -loop-extract"
https://llvm.org/bugs/show_bug.cgi?id=31107
Bug ID: 31107
Summary: wrong code with "opt -inline -instrprof -loop-extract"
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ clang -v
clang version 4.0.0 (trunk 287325)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -c -w -emit-llvm -o small.bc small.c
$
$ llc -o small.s small.bc
$ gcc small.s
$ ./a.out
1
$
$ opt -inline -instrprof -loop-extract -o small-opt.bc small.bc
$ llc -o small-opt.s small-opt.bc
$ gcc small-opt.s
$ ./a.out
2
$
-
int printf (const char *, ...);
int a, c, e;
void fn1 ()
{
int b[] = { 0, 2, 0, 0, 0, 0, 0 };
}
void fn2 ()
{
int d[3] = { 0, 0, 0 }, e[7];
}
int fn3 ()
{
int g[3];
for (;;)
{
int h[] = { 1, 1 };
fn1 ();
g;
if (e < 1)
return h[1];
}
}
int main ()
{
c = fn3 ();
fn2 ();
for (; a < 1; a++)
printf ("%d\n", c);
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 31108] New: wrong code with "opt -inline -loop-extract"
https://llvm.org/bugs/show_bug.cgi?id=31108
Bug ID: 31108
Summary: wrong code with "opt -inline -loop-extract"
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: s...@cs.ucdavis.edu
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ clang -v
clang version 4.0.0 (trunk 287325)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/clang-trunk/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clang -c -w -emit-llvm -o small.bc small.c
$
$ llc -o small.s small.bc
$ gcc small.s
$ ./a.out
$
$ opt -inline -loop-extract -o small-opt.bc small.bc
$ llc -o small-opt.s small-opt.bc
$ gcc small-opt.s
$ timeout -s 9 10 ./a.out
Killed
$
--
int a;
void fn1 (int p)
{
int b[] = { 1 };
}
void fn2 ()
{
while (a)
{
int c[] = { 2 }, d;
d;
}
}
void fn3 ()
{
int e = 0, f[7];
for (; e < 3; e++)
fn1 ((f, 7));
}
int main ()
{
fn3 ();
fn2 ();
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 31109] New: lld fails with "relocation R_X86_64_32 out of range"
https://llvm.org/bugs/show_bug.cgi?id=31109 Bug ID: 31109 Summary: lld fails with "relocation R_X86_64_32 out of range" Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: l...@inglorion.net CC: llvm-bugs@lists.llvm.org Classification: Unclassified I tried to link a large executable with lld, and it failed, emitting a lot of "relocation R_X86_64_32 out of range errors" and requiring to be killed with SIGKILL. Using a different linker, I was able to successfully create a working executable. The executable has a large (more than 2**32 bytes) .debug_info section in it. What I did: Compiled Chromium with profile-guided optimization and ThinLTO. The instrumented build succeeded and allowed me to gather profile data. Using the profile data to create an optimized build, the build succeeded up to the link step, which failed with relocation out of range errors. -- 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 31110] New: Clang has pretty catastrophic failure of error recovery when a method's signature has an invalid type
https://llvm.org/bugs/show_bug.cgi?id=31110
Bug ID: 31110
Summary: Clang has pretty catastrophic failure of error
recovery when a method's signature has an invalid type
Product: clang
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: chandl...@gmail.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Consider this test case:
template struct S {
S() {}
~S() {}
void foobar(U mumble) {}
};
class Base {
S dummy;
int i;
public:
virtual ~Base() {}
};
struct Derived : Base {
virtual void method() {}
};
void test() {
Derived d;
Base *b = &d;
}
Clang, all the way back to 3.2, has really bad recovery for numerous cases like
this. At the very least:
1) Just because the member function is invalid, we mark all of the
instantiations of the class template invalid. This might be OK if doing that
effectively suppressed subsequent errors on that invalid class and we bailed
out of instantiation. But neither seems to be true.
2) In the face of an invalid member of a base class with a virtual destructor,
we manage to leave things in a state where essentially all of the errors and
warnings specific to the base <-> derived relationship are bogus.
The above test case only triggers this once, but in many cases, the above leads
a single root cause error to produce *hundreds* of diagnostics that have
literally nothing to do with anything connected to the class template that was
invalid.
--
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 8673] poor error recovery on incorrect type name in method argument
https://llvm.org/bugs/show_bug.cgi?id=8673
Chandler Carruth changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||chandl...@gmail.com
Resolution|--- |FIXED
--- Comment #1 from Chandler Carruth ---
This bug is ancient. Not sure when it got fixed but it did:
% cat PR8673.cpp
class ABC;
class foo {
void bar(ABC *X);
};
void foo::bar(DEF *X) {}
% clang++ PR8673.cpp
PR8673.cpp:5:15: error: unknown type name 'DEF'
void foo::bar(DEF *X) {}
^
1 error generated.
--
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 31111] New: vectors with length 3 and width 8 or 16 cannot be efficiently loaded
https://llvm.org/bugs/show_bug.cgi?id=3
Bug ID: 3
Summary: vectors with length 3 and width 8 or 16 cannot be
efficiently loaded
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: srol...@vmware.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
This is probably not really important, more noticed this by accident, but
fetching <3 x i8> and <3 x i16> values (to fit into <16 x i8> and <8 x i16>
vectors) requires manual decomposition to generate efficient loads.
(Obviously, just (unaligned) fetching a vector with 4 elements would not have
these problems, but that may not always be possible.)
The standard way we to do this (note that usually we'd fill up the rest of the
vector with more elements) is:
define <4 x i32> @load3x8(i8* %ptr, i32 %offset) {
entry:
%0 = getelementptr i8, i8* %ptr, i32 %offset
%ad0 = bitcast i8* %0 to i24*
%va0 = load i24, i24* %ad0, align 1
%va0z = zext i24 %va0 to i32
%shuf = insertelement <4 x i32> undef, i32 %va0z, i32 0
ret <4 x i32> %shuf
}
The code generated for that is ok, but due to the scalar zext has some extra
instructions:
movslq %esi, %rcx
movzwl (%rdi,%rcx), %eax
movzbl 2(%rdi,%rcx), %ecx
shll$16, %ecx
orl %eax, %ecx
vmovd %ecx, %xmm0
ret
So, trying to get rid of that, an attempt would look like this:
define <4 x i32> @load3x8vec(i8* %ptr, i32 %offset) {
entry:
%0 = getelementptr i8, i8* %ptr, i32 %offset
%ad0 = bitcast i8* %0 to <3 x i8>*
%va0 = load <3 x i8>, <3 x i8>* %ad0, align 1
%va0s = shufflevector <3 x i8> %va0, <3 x i8> undef, <16 x i32>
%res = bitcast <16 x i8> %va0s to <4 x i32>
ret <4 x i32> %res
}
This could be done with just one pinsrw, one pinsrb (with sse41 at least),
however llvm produces this wtf piece of assembly (with avx, the sse2 case looks
different but just as terrible):
movslq %esi, %rax
movzwl (%rdi,%rax), %ecx
vmovd %rcx, %xmm0
vpshufb .LCPI1_0(%rip), %xmm0, %xmm0
vmovd %xmm0, %ecx
movzbl 2(%rdi,%rax), %eax
vmovd %ecx, %xmm0
vpextrb $0, %xmm0, %ecx
vpextrb $1, %xmm0, %edx
shll$8, %edx
orl %ecx, %edx
vpinsrw $0, %edx, %xmm0, %xmm0
vpinsrw $1, %eax, %xmm0, %xmm0
ret
There is some very serious anti-optimization going on here...
The only way to force llvm to spit out efficient code seems to be to decompose
this into 2 loads manually, which is quite annoying:
define <4 x i32> @load3x8manual(i8* %ptr, i32 %offset) {
entry:
%0 = getelementptr i8, i8* %ptr, i32 %offset
%ptr1 = getelementptr i8, i8* %ptr, i32 2
%ad0b = getelementptr i8, i8* %ptr1, i32 %offset
%ad0 = bitcast i8* %0 to i16*
%va0w = load i16, i16* %ad0, align 1
%va0b = load i8, i8* %ad0b, align 1
%shuf0 = insertelement <8 x i16> undef, i16 %va0w, i32 0
%shufc = bitcast <8 x i16> %shuf0 to <16 x i8>
%shuf1 = insertelement <16 x i8> %shufc, i8 %va0b, i32 2
%res = bitcast <16 x i8> %shuf1 to <4 x i32>
ret <4 x i32> %res
}
which produces:
movslq %esi, %rax
movzwl (%rdi,%rax), %ecx
vmovd %ecx, %xmm0
vpinsrb $2, 2(%rdi,%rax), %xmm0, %xmm0
ret
(Note this is still fail as it should just be vpinsrw instead of the
movzwl+vmovd - however when actually fetching 3 more such values to fill up the
vector then llvm will indeed use the vpinsrw instead. And with sse2 only this
doesn't turn out that well but it's probably impossible to beat the scalar
i24->i32 ZExt there.)
The <3 x i16> case pretty much fails all the same, still resorting to some
seriously weird scalar extraction... However, fetching a <3 x i32> vector that
way works fine without hand-holding (fetching as i96 still produces some extra
instructions, but fetching as a vector works fine):
define <4 x i32> @load3x32vec(i8* %ptr, i32 %offset) {
entry:
%0 = getelementptr i8, i8* %ptr, i32 %offset
%ad0 = bitcast i8* %0 to <3 x i32>*
%va0 = load <3 x i32>, <3 x i32>* %ad0, align 4
%shuf = shufflevector <3 x i32> %va0, <3 x i32> undef, <4 x i32>
ret <4 x i32> %shuf
}
movslq %esi, %rax
vmovq (%rdi,%rax), %xmm0
vpinsrd $2, 8(%rdi,%rax), %xmm0, %xmm0
ret
(Though with sse2 only llvm will do:
movslq %esi, %rax
movq(%rdi,%rax), %xmm0 # xmm0 = mem[0],zero
movd8(%rdi,%rax), %xmm1 # xmm1 = mem[0],zero,zero,zero
shufps $48, %xmm0, %xmm1 # xmm1 = xmm1[0,0],xmm0[3,0]
shufps $132, %xmm1, %xmm0 # xmm0 = xmm0[0,1],xmm1[0,2]
retq
Which is definitely one shufps too many - even a simple unpack would have done)
(I didn't try other non-power-of
[llvm-bugs] [Bug 31096] Multi-level pointers not disambiguated, even with strict aliasing
https://llvm.org/bugs/show_bug.cgi?id=31096 Daniel Berlin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Daniel Berlin --- Yes, TBAA was not being added to the pass pipeline properly. Sigh. -- 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
