[llvm-bugs] Issue 10729 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Timeout in llvm_llvm-isel-fuzzer--x86_64-O2
Comment #2 on issue 10729 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: Timeout in llvm_llvm-isel-fuzzer--x86_64-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10729#c2 ClusterFuzz has detected this issue as fixed in range 201810030224:201810040228. Detailed report: https://oss-fuzz.com/testcase?key=5189572871323648 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--x86_64-O2 Fuzz target binary: llvm-isel-fuzzer--x86_64-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Timeout (exceeds 25 secs) Crash Address: Crash State: llvm_llvm-isel-fuzzer--x86_64-O2 Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201710160455:201710190451 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201810030224:201810040228 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5189572871323648 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10729 in oss-fuzz: llvm/llvm-isel-fuzzer--x86_64-O2: Timeout in llvm_llvm-isel-fuzzer--x86_64-O2
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 10729 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--x86_64-O2: Timeout in llvm_llvm-isel-fuzzer--x86_64-O2 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10729#c3 ClusterFuzz testcase 5189572871323648 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39131] CommandObjectType.cpp:1063:7: error: cannot initialize aggregate of type 'const lldb_private::OptionDefinition [2]' with a compound literal
https://bugs.llvm.org/show_bug.cgi?id=39131 Sylvestre Ledru changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Sylvestre Ledru --- Still fails with Debian jessie: $ cd "/build/llvm-toolchain-snapshot-8~svn343751/build-llvm/tools/lldb/source/Commands" && /usr/bin/g++-4.9 -DHAVE_ROUND -DLLDB_CONFIGURATION_RELEASE -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I"/build/llvm-toolchain-snapshot-8~svn343751/build-llvm/tools/lldb/source/Commands" -I"/build/llvm-toolchain-snapshot-8~svn343751/tools/lldb/source/Commands" -I"/build/llvm-toolchain-snapshot-8~svn343751/build-llvm/tools/lldb/include" -I"/build/llvm-toolchain-snapshot-8~svn343751/tools/lldb/include" -I"/build/llvm-toolchain-snapshot-8~svn343751/build-llvm/include" -I"/build/llvm-toolchain-snapshot-8~svn343751/include" -I/usr/include/python2.7 -I"/build/llvm-toolchain-snapshot-8~svn343751/tools/clang/include" -I"/build/llvm-toolchain-snapshot-8~svn343751/build-llvm/tools/lldb/../clang/include" -I"/build/llvm-toolchain-snapshot-8~svn343751/tools/lldb/source/." -fuse-ld=gold -Wl,--no-keep-files-mapped -Wl,--no-map-whole-files -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O2 -DNDEBUG-fno-exceptions -o CMakeFiles/lldbCommands.dir/CommandObjectType.cpp.o -c "/build/llvm-toolchain-snapshot-8~svn343751/tools/lldb/source/Commands/CommandObjectType.cpp" /build/llvm-toolchain-snapshot-8~svn343751/tools/lldb/source/Commands/CommandObjectType.cpp: In member function 'llvm::ArrayRef CommandObjectTypeFormatterList::CommandOptions::GetDefinitions()': /build/llvm-toolchain-snapshot-8~svn343751/tools/lldb/source/Commands/CommandObjectType.cpp:1063:7: error: cannot initialize aggregate of type 'const lldb_private::OptionDefinition [2]' with a compound literal }; ^ -- 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 39171] New: [NVPTX] Early call to __kmpc_global_thread_num
https://bugs.llvm.org/show_bug.cgi?id=39171
Bug ID: 39171
Summary: [NVPTX] Early call to __kmpc_global_thread_num
Product: OpenMP
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: hah...@hahnjo.de
CC: llvm-bugs@lists.llvm.org
__kmpc_global_thread_num() in libomptarget-nvptx has to handle SPMD vs Generic
differently. The decision is based on the current value of "execution_param"
which is initialized by __kmpc_kernel_init() / __kmpc_spmd_kernel_init().
However current Clang trunk calls __kmpc_global_thread_num() from the entry
BasicBlock which is incorrect and might read from uninitialized memory.
Example for SPMD construct:
#pragma omp target parallel
{ }
This generates the following LLVM IR:
; Function Attrs: noinline norecurse nounwind optnone
define weak void @__omp_offloading_45_ba1b925f_main_l5() #0 {
entry:
%.zero.addr = alloca i32, align 4
%0 = call i32 bitcast (i32 (i8*)* @__kmpc_global_thread_num to i32
(%struct.ident_t*)*)(%struct.ident_t* @0)
%.threadid_temp. = alloca i32, align 4
store i32 0, i32* %.zero.addr, align 4
%nvptx_num_threads = call i32 @llvm.nvvm.read.ptx.sreg.ntid.x(), !range !12
call void @__kmpc_spmd_kernel_init(i32 %nvptx_num_threads, i16 1, i16 1)
call void @__kmpc_data_sharing_init_stack_spmd()
br label %.execute
.execute: ; preds = %entry
store i32 %0, i32* %.threadid_temp., align 4
call void @__omp_outlined__(i32* %.threadid_temp., i32* %.zero.addr) #11
br label %.omp.deinit
.omp.deinit: ; preds = %.execute
call void @__kmpc_spmd_kernel_deinit()
br label %.exit
.exit:; preds = %.omp.deinit
ret void
}
Example for Generic construct (num_threads prohibits SPMD mode):
#pragma omp target parallel num_threads(2)
{ }
The worker and kernel functions look like this:
; Function Attrs: noinline norecurse nounwind
define internal void @__omp_offloading_45_ba294015_main_l5_worker() #0 {
entry:
%work_fn = alloca i8*, align 8
%exec_status = alloca i8, align 1
%0 = call i32 bitcast (i32 (i8*)* @__kmpc_global_thread_num to i32
(%struct.ident_t*)*)(%struct.ident_t* @0)
store i8* null, i8** %work_fn, align 8
store i8 0, i8* %exec_status, align 1
br label %.await.work
.await.work: ; preds = %.barrier.parallel,
%entry
call void @llvm.nvvm.barrier0()
%1 = call i1 @__kmpc_kernel_parallel(i8** %work_fn, i16 1)
%2 = zext i1 %1 to i8
store i8 %2, i8* %exec_status, align 1
%3 = load i8*, i8** %work_fn, align 8
%should_terminate = icmp eq i8* %3, null
br i1 %should_terminate, label %.exit, label %.select.workers
.select.workers: ; preds = %.await.work
%4 = load i8, i8* %exec_status, align 1
%is_active = icmp ne i8 %4, 0
br i1 %is_active, label %.execute.parallel, label %.barrier.parallel
.execute.parallel:; preds = %.select.workers
%5 = load i8*, i8** %work_fn, align 8
%work_match = icmp eq i8* %5, bitcast (void (i16, i32)*
@__omp_outlined___wrapper to i8*)
br i1 %work_match, label %.execute.fn, label %.check.next
.execute.fn: ; preds = %.execute.parallel
call void @__omp_outlined___wrapper(i16 0, i32 %0) #12
br label %.terminate.parallel
.check.next: ; preds = %.execute.parallel
%6 = bitcast i8* %3 to void (i16, i32)*
call void %6(i16 0, i32 %0)
br label %.terminate.parallel
.terminate.parallel: ; preds = %.check.next,
%.execute.fn
call void @__kmpc_kernel_end_parallel()
br label %.barrier.parallel
.barrier.parallel:; preds =
%.terminate.parallel, %.select.workers
call void @llvm.nvvm.barrier0()
br label %.await.work
.exit:; preds = %.await.work
ret void
}
; Function Attrs: noinline norecurse nounwind optnone
define weak void @__omp_offloading_45_ba294015_main_l5() #1 {
entry:
%0 = call i32 bitcast (i32 (i8*)* @__kmpc_global_thread_num to i32
(%struct.ident_t*)*)(%struct.ident_t* @0)
%.zero.addr = alloca i32, align 4
store i32 0, i32* %.zero.addr, align 4
%nvptx_tid = call i32 @llvm.nvvm.read.ptx.sreg.tid.x(), !range !12
%nvptx_num_threads = call i32 @llvm.nvvm.read.ptx.sreg.ntid.x(), !range !13
%nvptx_warp_size = call i32 @llvm.nvvm.read.ptx.sreg.warpsize(), !range !14
%thread_limit = sub nuw i32 %nvptx_num_threads, %nvptx_warp_size
%1 = icmp ult i32 %nvptx_tid, %thread_limit
br i1 %1, label %.worker, label %.mastercheck
.worker: ; preds = %entry
call void @__omp_offloading_
[llvm-bugs] [Bug 39172] New: [NVPTX] Wrong results or hang on GPU when using lastprivate() on SPMD construct with full runtime
https://bugs.llvm.org/show_bug.cgi?id=39172
Bug ID: 39172
Summary: [NVPTX] Wrong results or hang on GPU when using
lastprivate() on SPMD construct with full runtime
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Clang Compiler Support
Assignee: unassignedclangb...@nondot.org
Reporter: hah...@hahnjo.de
CC: llvm-bugs@lists.llvm.org
The following program uses an SPMD construct with lastprivate() clause and the
runtime has to be initialized because of schedule(dynamic):
#include
#include
int main(int argc, char *argv[]) {
int last;
#pragma omp target teams distribute parallel for map(from: last)
lastprivate(last) schedule(dynamic)
for (int i = 0; i < 1; i++) {
last = i;
}
printf("last = %d\n", last);
return EXIT_SUCCESS;
}
Compiled with current Clang trunk the application delivers wrong results (last
= 0) with -O0 and -O1 and hangs with -O2 and -O3. I think this is due to the
same problem: The generated code calls __kmpc_data_sharing_push_stack() to get
memory for storing "int last;" to implement lastprivate(). This works if the
runtime is uninitialized because there is a special case in libomptarget-nvptx
which returns the *same memory location for all threads* (see
https://reviews.llvm.org/D51875).
However the original contract of __kmpc_data_sharing_push_stack() was to return
*unique memory for each thread* which explains the wrong result. For higher
optimization levels I'd guess that LLVM exploits undefined behaviour somewhere
which makes the application hang?
The only solution I can think of is to introduce new entry points in
libomptarget-nvptx with the required contract: Return the same memory location
for all calling threads in the same thread block. Opinions?
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #7 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c7 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-079bf21a-04cb-4737-bc17-93b5e90e1c30.txt -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39173] New: Merge r340386 into the 7.0 branch
https://bugs.llvm.org/show_bug.cgi?id=39173 Bug ID: 39173 Summary: Merge r340386 into the 7.0 branch Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: nemanja.i@gmail.com CC: llvm-bugs@lists.llvm.org Without this patch, clang cannot be used as the build compiler for ToT clang/llvm with shared libraries due to failures in LIT tests with the built compiler. We need this merged into 7.0.1 so that we can use that as the build compiler. -- 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 37855] [Analyzer][Z3] Wrong comparison operation being generated from ranged constraint
https://bugs.llvm.org/show_bug.cgi?id=37855 Mikhail changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mikhail --- Fixed in r335926. -- 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 39174] New: Use "bt" for switch select from bitmask?
https://bugs.llvm.org/show_bug.cgi?id=39174
Bug ID: 39174
Summary: Use "bt" for switch select from bitmask?
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: h...@chromium.org
CC: llvm-bugs@lists.llvm.org
For example:
bool f(int x) {
switch (x) {
case 0: return true;
case 1: return true;
case 2: return false;
case 3: return false;
case 4: return true;
}
}
SimplifyCFG will generate a "table lookup" from a bitmask, and on X86_64 we end
up with:
f(int): # @f(int)
# %bb.0:
mov al, 19
mov ecx, edi
shr al, cl
and al, 1
ret
I wonder if we could get tighter code with the BT instruction.
--
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 39175] New: std::is_nothrow_constructibe doesn't work well in case of std::optional<...>
https://bugs.llvm.org/show_bug.cgi?id=39175
Bug ID: 39175
Summary: std::is_nothrow_constructibe doesn't work well in case
of std::optional<...>
Product: libc++
Version: 7.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mate@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Hello,
The following code fails:
>>>
#include
#include
struct FooThrow {
FooThrow() noexcept(true) {}
~FooThrow() noexcept(false) {} // <-- if true: OK
};
static_assert(noexcept(std::optional()));
static_assert(noexcept(std::optional(std::nullopt)));
static_assert(std::is_nothrow_constructible_v,
std::nullopt_t>);
static_assert(std::is_nothrow_constructible_v>);
<<<
(gcc compiles it)
I assume it is a library bug, because "noexcept(FooThrow())" is false with gcc
and clang too.
Best Regards,
Mate Pek
--
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 39176] New: [SimplifyCFG] Merge DebugLoc when speculatively hoisting store instruction
https://bugs.llvm.org/show_bug.cgi?id=39176 Bug ID: 39176 Summary: [SimplifyCFG] Merge DebugLoc when speculatively hoisting store instruction Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: sontuan.vu...@gmail.com CC: llvm-bugs@lists.llvm.org Hello, In lib/Transforms/Utils/SimplifyCFG.cpp, function 'SpeculativelyExecuteBB()', when we create a new SelectInst (named 'spec.store.select') and make it operand 0 of the speculated store instruction, why do we need to modify the debug location of the speculated store? IIUC, the debug location of the speculated store should not be changed: the debug location of the branching instruction is already attached to the SelectInst. Thanks for your time -- 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 39177] New: Summary: LibCallSimplifier (of instcombine) crashes on aliased lib function
https://bugs.llvm.org/show_bug.cgi?id=39177 Bug ID: 39177 Summary: Summary: LibCallSimplifier (of instcombine) crashes on aliased lib function Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Transformation Utilities Assignee: unassignedb...@nondot.org Reporter: julian.buen...@rwth-aachen.de CC: llvm-bugs@lists.llvm.org Created attachment 20959 --> https://bugs.llvm.org/attachment.cgi?id=20959&action=edit minimal test case While trying to test some programs with KLEE, David Laprell came up with an issue previously noted here: http://lists.llvm.org/pipermail/llvm-dev/2017-July/115957.html David was able to reduce the input to KLEE (still linking against klee-uclibc) to a minimum. >From this I was able to reduce it to the attached program crashing opt -instcombine / clang -O1 (version 8.0.0, trunk 343759). In this program, "frwite" is aliased to "__fwrite_alias". The core issue seems to be in lib/Transforms/Utils/BuildLibCalls.cpp's method llvm::emitFWrite(): Constant *F = M->getOrInsertFunction( FWriteName, DL.getIntPtrType(Context), B.getInt8PtrTy(), DL.getIntPtrType(Context), DL.getIntPtrType(Context), File->getType()); if (File->getType()->isPointerTy()) inferLibFuncAttributes(*M->getFunction(FWriteName), *TLI); The code assumes that after calling getOrInsertFunction(), it is safe to say that a function of FWriteName will exist. This is not true, as getOrInsertFunction() returns a GlobalAlias, but getFunction() returns nullptr (as GlobalAlias cannot be casted to Function). The same pattern (and thus problem) seems to be present accross most llvm::emit* functions in BuildLibCalls.cpp, but I haven't investigated it further. Steps to reproduce: $ ../llvm-trunk/build/bin/clang -Xclang -disable-O0-optnone -c -emit-llvm crash.c $ ../llvm-trunk/build/bin/opt -instcombine crash.bc -o crash.opt.bc Stack dump: 0. Program arguments: ../llvm-trunk/build/bin/opt -instcombine crash.bc -o crash.opt.bc 1. Running pass 'Function Pass Manager' on module 'crash.bc'. 2. Running pass 'Combine redundant instructions' on function '@main' [...] #4 0x7f742729e1b0 __restore_rt (/lib64/libpthread.so.0+0x121b0) #5 0x01245bd6 llvm::GlobalValue::getParent() const /home/jb/llvm-trunk/build/../include/llvm/IR/GlobalValue.h:567:0 #6 0x018f1e9d llvm::TargetLibraryInfoImpl::getLibFunc(llvm::Function const&, llvm::LibFunc&) const /home/jb/llvm-trunk/build/../lib/Analysis/TargetLibraryInfo.cpp:1375:0 #7 0x01616716 llvm::TargetLibraryInfo::getLibFunc(llvm::Function const&, llvm::LibFunc&) const /home/jb/llvm-trunk/build/../include/llvm/Analysis/TargetLibraryInfo.h:237:0 #8 0x02872a22 llvm::inferLibFuncAttributes(llvm::Function&, llvm::TargetLibraryInfo const&) /home/jb/llvm-trunk/build/../lib/Transforms/Utils/BuildLibCalls.cpp:126:0 #9 0x02876ab1 llvm::emitFWrite(llvm::Value*, llvm::Value*, llvm::Value*, llvm::IRBuilder&, llvm::DataLayout const&, llvm::TargetLibraryInfo const*) /home/jb/llvm-trunk/build/../lib/Transforms/Utils/BuildLibCalls.cpp:1093:0 [...] Segmentation fault (core dumped) This behavior was found in the course of the SYMBIOSYS research project at COMSYS, RWTH Aachen University. This research is supported by the European Research Council (ERC) under the EU's Horizon 2020 Research and Innovation Programme grant agreement n. 647295 (SYMBIOSYS). -- 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 36951] [X86] SandyBridge/Haswell/Broadwell/Skylake scheduler models lose the ReadAdvance information for all instructions that load from memory and read another operand from a registe
https://bugs.llvm.org/show_bug.cgi?id=36951 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Pilgrim --- Works in trunk - added test case at rL343795 -- 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 32325] [META][X86] Improve implementation and use of X86 scheduler models
https://bugs.llvm.org/show_bug.cgi?id=32325 Bug 32325 depends on bug 36951, which changed state. Bug 36951 Summary: [X86] SandyBridge/Haswell/Broadwell/Skylake scheduler models lose the ReadAdvance information for all instructions that load from memory and read another operand from a register https://bugs.llvm.org/show_bug.cgi?id=36951 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 8990] configure complains of plugin for lack of dlopen on MSYS+MinGW
https://bugs.llvm.org/show_bug.cgi?id=8990 Gleb Popov <6year...@gmail.com> changed: What|Removed |Added CC||6year...@gmail.com Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Gleb Popov <6year...@gmail.com> --- LLVM has no autoconf build system anymore. This is overcome by events. -- 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 39102] [llvm-exegesis] UOps Analysis is very slow
https://bugs.llvm.org/show_bug.cgi?id=39102 Simon Pilgrim changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|343690 |343690, 343771 Status|NEW |RESOLVED --- Comment #3 from Simon Pilgrim --- Fixed by rL343771 - thanks Guillaume! -- 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 39178] New: [X86] SimplifyDemandedBits failure to simplify PMULDQ/PMULUDQ
https://bugs.llvm.org/show_bug.cgi?id=39178
Bug ID: 39178
Summary: [X86] SimplifyDemandedBits failure to simplify
PMULDQ/PMULUDQ
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: andrea.dibia...@gmail.com, craig.top...@gmail.com,
llvm-bugs@lists.llvm.org, spatel+l...@rotateright.com
define <2 x i64> @muludq_demanded_bits(<4 x i32>, <4 x i32>) {
%3 = shufflevector <4 x i32> %0, <4 x i32> , <4 x i32>
%4 = shufflevector <4 x i32> %1, <4 x i32> , <4 x i32>
%5 = bitcast <4 x i32> %3 to <2 x i64>
%6 = bitcast <4 x i32> %4 to <2 x i64>
%7 = mul <2 x i64> %6, %5
ret <2 x i64> %7
}
llc -mcpu=btver2
vpxor %xmm2, %xmm2, %xmm2
vpblendw$204, %xmm2, %xmm0, %xmm0 # xmm0 =
xmm0[0,1],xmm2[2,3],xmm0[4,5],xmm2[6,7]
vpblendw$204, %xmm2, %xmm1, %xmm1 # xmm1 =
xmm1[0,1],xmm2[2,3],xmm1[4,5],xmm2[6,7]
vpmuludq%xmm0, %xmm1, %xmm0
retq
The vpblendw can be removed as PMULDQ/PMULUDQ only use the bottom 32-bits of
each i64 element
--
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 39179] New: -opt-bisect-limit output is written out of order when performing ThinLTO
https://bugs.llvm.org/show_bug.cgi?id=39179
Bug ID: 39179
Summary: -opt-bisect-limit output is written out of order when
performing ThinLTO
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: greg.bedw...@sony.com
CC: andrew.kay...@intel.com, fedor.v.serg...@gmail.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com, pe...@pcc.me.uk,
tejohn...@google.com
Using r343783. Potentially related to the recent llvm-dev discussions
("OptBisect implementation for new pass manager") which touch on the
interaction between OptBisect and parallel compilation.
The symptom I've observed here is that the output text is all mixed up. I'm
not sure if that's the extent of the issue or whether the passes associated
with each counter value differ too (I've not managed to observe that happening,
but the messed up output text makes it hard to figure that out). Obvious
workaround is to explicitly specify -Wl,-thinlto-jobs=1 at the same time. If
the resolution of this bug is "this is as expected, just specify
-Wl,-thinlto-jobs=1" then that's fine, but I wanted to highlight it as it
relates to recent discussions.
greg@greg-win10:/mnt/c/tmp/thinlto-bisect$ cat 1.cpp
extern int f(int);
int main(int argc, char**) {
int result = 0;
for (int i = 0; i < argc; ++i)
result += f(i);
return result;
}
greg@greg-win10:/mnt/c/tmp/thinlto-bisect$ cat 2.cpp
extern int f(int x) {
for (int i = x; x; --i) {
if (i & 5)
return i;
}
return x;
}
greg@greg-win10:/mnt/c/tmp/thinlto-bisect$ clang++ -c -O2 -flto=thin 1.cpp
2.cpp
greg@greg-win10:/mnt/c/tmp/thinlto-bisect$ clang++ 1.o 2.o -fuse-ld=lld
-Wl,-mllvm -Wl,-opt-bisect-limit=1000
BISECT: running pass (1) Dead Global Elimination on module (ld-temp.o)
BISECT: running pass (2) Infer set function attributes on module (ld-temp.o)
BISECT: running pass (3) Interprocedural Sparse Conditional Constant
Propagation on module (ld-temp.o)
BISECT: running pass (4) Called Value Propagation on module (ld-temp.o)
BISECT: running pass (5) Deduce function attributes on SCC (<>)
BISECT: running pass (6) Deduce function attributes in RPO on module
(ld-temp.o)
BISECT: running pass (7) Global splitter on module (ld-temp.o)
BISECT: running pass (8) Whole program devirtualization on module (ld-temp.o)
BISECT: running pass (9) Global Variable Optimizer on module (ld-temp.o)
BISECT: running pass (10) Merge Duplicate Global Constants on module
(ld-temp.o)
BISECT: running pass (11) Dead Argument Elimination on module (ld-temp.o)
BISECT: running pass (12) Function Integration/Inlining on SCC (<>)
BISECT: running pass (13) Remove unused exception handling info on SCC (<>)
BISECT: running pass (14) Global Variable Optimizer on module (ld-temp.o)
BISECT: running pass (15) Dead Global Elimination on module (ld-temp.o)
BISECT: running pass (16) Promote 'by reference' arguments to scalars on SCC
(<>)
BISECT: running pass (17) Deduce function attributes on SCC (<>)
BISECT: running pass (18) Eliminate Available Externally Globals on module
(ld-temp.o)
BISECT: running pass (19) Dead Global Elimination on module (ld-temp.o)
BISECT: running pass (BISECT: 20running pass ) (Whole program
devirtualization21 on ) module (2.o)Whole program devirtualization
on module (1.o)BISECT:
running pass BISECT: (running pass 22() 23Infer set function attributes) on
Infer set function attributesmodule (2.o) on
module (1.o)BISECT:
running pass BISECT: (running pass 24() 25Interprocedural Sparse Conditional
Constant Propagation) on Interprocedural Sparse Conditional Constant
Propagationmodule (2.o) on
module (1.o)BISECT:
running pass BISECT: (running pass 26() 27Called Value Propagation) on Called
Value Propagationmodule (2.o) on
module (1.o)
BISECT: BISECT: running pass running pass ((2829) ) Global Variable
OptimizerGlobal Variable Optimizer on on module (2.o)module (1.o)
BISECT: BISECT: running pass running pass ((3031) ) Promote Memory to
RegisterPromote Memory to Register on on function (_Z1fi)function (main)
BISECT: BISECT: running pass running pass ((3233) ) Dead Argument
EliminationPromote Memory to Register on on module (2.o)function (_Z1fi)
BISECT: BISECT: running pass running pass ((3435) ) Combine redundant
instructionsDead Argument Elimination on on function (_Z1fi)module (1.o)
BISECT: BISECT: running pass running pass ((3637) ) Simplify the CFGCombine
redundant instructions on on function (_Z1fi)function (main)
BISECT: running pass (38) Simplify the CFG on function (main)
BISECT: running pass (39) Remove unused exception handling info on SCC (_Z1fi)
BISECT: BISECT: running pass running pass ((4041) ) Function
Integration/InliningCombine redun
[llvm-bugs] [Bug 39180] New: Clang compiler failed with error: no matching member function for call to 'f'
https://bugs.llvm.org/show_bug.cgi?id=39180
Bug ID: 39180
Summary: Clang compiler failed with error: no matching member
function for call to 'f'
Product: clang
Version: 6.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: soumi.ma...@intel.com
CC: dgre...@apple.com, llvm-bugs@lists.llvm.org
Clang compiler failed on windows with error: no matching member function for
call to 'f' for the following example.
bug.cpp:10:19: error: no matching member function for call to 'f'
int b = a.f();
~~^
bug.cpp:2:34: note: candidate template ignored: deduced too few arguments for
expanded pack 'T'; no argument for 1st
expanded parameter in deduced argument pack <>
template int f() {
^
1 error generated.
Microsoft visual studio 2017 passes the example.
ksh-3.2$ cl -c -std:c++17 bug.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.13.26131.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
bug.cpp
ksh-3.2$ cat bug.cpp
template struct Tuple_ { // _VARIADIC_TEMPLATE
template int f() {
return sizeof...(Types);
}
};
int main(int argc, char *argv[])
{
Tuple_ a;
int b = a.f();
}
Soumi Manna
Intel C/C++ Front-end team
--
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 22206] extra moves generated for unary SSE ops
https://bugs.llvm.org/show_bug.cgi?id=22206 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Sanjay Patel --- I don't know which patch fixed this, but we get the right output as of r343774: sqrtss %xmm0, %xmm1 addss %xmm1, %xmm0 Test added at: https://reviews.llvm.org/rL343803 -- 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 39181] New: aarch64 unpredictable instruction from inline assembly
https://bugs.llvm.org/show_bug.cgi?id=39181
Bug ID: 39181
Summary: aarch64 unpredictable instruction from inline assembly
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: compn...@compnerd.org
CC: llvm-bugs@lists.llvm.org
```
// %RUN: %clang_cc1 -triple aarch64 -O1 -emit-obj -o /dev/null -x c %s
typedef __UINTPTR_TYPE__ uintptr_t;
typedef __UINT32_TYPE__ uint32_t;
static _Bool g(uintptr_t *destination,
uintptr_t old __attribute__((__unused__)), uintptr_t value) {
uint32_t status;
__asm__("stxr %w[status], %x[value], [%x[location]]"
: [status] "=r" (status), "=m" (*destination)
: [value] "r" (value), [location] "r" (destination));
return !status;
}
void f(void) {
uintptr_t value;
uintptr_t destination;
g(&destination, 0, value);
}
```
Marking status as an early clobber doesn't seem to help either. I've not yet
reduced this down, but, putting here to make sure that we don't forget about
it. This did work with clang 6 at least.
--
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 39182] New: Clang compiled with mingw-w64 emits available_externally for IsWindowsXPOrGreater()
https://bugs.llvm.org/show_bug.cgi?id=39182
Bug ID: 39182
Summary: Clang compiled with mingw-w64 emits
available_externally for IsWindowsXPOrGreater()
Product: clang
Version: 7.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: 6year...@gmail.com
CC: llvm-bugs@lists.llvm.org
I've compiled release_70 branch with recent mingw-w64 toolchain (GCC 8.2.0) and
using produced Clang to compile following program:
#include
#include
int main(int argc, char* argv[])
{
IsWindowsXPOrGreater();
printf("OK\n");
return 0;
}
It fails on linking stage with "undefined reference to IsWindowsXPOrGreater".
When I use clang.exe from the official installer, it works fine.
I examined -S -emit-llvm output and found that my clang emits
define available_externally dso_local i32 @IsWindowsXPOrGreater {
...
}
while official clang emits
define linkonce_odr dso_local i32 @IsWindowsXPOrGreater {
...
}
Am I missing something, or it is a bug in Clang?
For reference, here is VersionHelpers.h source:
https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/include/versionhelpers.h
--
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 39183] New: tuple comparison operators return true for tuples of different sizes
https://bugs.llvm.org/show_bug.cgi?id=39183
Bug ID: 39183
Summary: tuple comparison operators return true for tuples of
different sizes
Product: libc++
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: tonyele...@hotmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
The following compiles cleanly under `clang++ -stdlib=libc++ -S a.cpp` :
#include
static_assert( std::tuple{ 1 } == std::tuple{ 1, 2 }, "" );
static_assert( std::tuple{ 0 } != std::tuple{ 1, 2 }, "" );
static_assert( std::tuple{ 0 } < std::tuple{ 1, 2 }, "" );
static_assert( std::tuple{ 2 } >= std::tuple{ 1, 2 }, "" );
..demonstrating that these comparison operators are returning true for pairs of
tuples of different sizes. This feels particularly problematic in the case of
operator==().
Under "tuple.rel", the standard says that these operators require
`sizeof...(TTypes) == sizeof...(UTypes)`, though I must confess I don't know
whether the standard mandates detection and reporting of violations of
requirements like these. Either way, I think it'd be very much better to do so
in this case.
I can reproduce this on Godbolt with "clang version 8.0.0 (trunk 343649)" (and
Clangs 6 and 7).
Thanks very much for all work on libc++.
--
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 39182] Clang compiled with mingw-w64 emits available_externally for IsWindowsXPOrGreater()
https://bugs.llvm.org/show_bug.cgi?id=39182 Gleb Popov <6year...@gmail.com> changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Gleb Popov <6year...@gmail.com> --- Using "static inline" indeed fixed the problem for me. Thanks for looking into that, I'll bug MinGW upstream. -- 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 39184] New: modules: `#pragma once` must appear before `#ifdef` when using `-fmodules`
https://bugs.llvm.org/show_bug.cgi?id=39184 Bug ID: 39184 Summary: modules: `#pragma once` must appear before `#ifdef` when using `-fmodules` Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Modules Assignee: unassignedclangb...@nondot.org Reporter: andrew...@gmail.com CC: dgre...@apple.com, llvm-bugs@lists.llvm.org When compiling with `-fmodules` (but not necessarily actually building modules), `#pragma once` guards don't work when appearing after a `#ifdef ...` guard. Example failing test: https://reviews.llvm.org/differential/diff/168367/. I couldn't find any supporting documentation saying that `#pragma once` must come first, but assuming this is true, then this probably isn't a bug (but maybe should then be a warning?). -- 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 39176] [SimplifyCFG] Merge DebugLoc when speculatively hoisting store instruction
https://bugs.llvm.org/show_bug.cgi?id=39176 David Blaikie changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from David Blaikie --- This current behavior looks right to me. If the speculated store kept line 3, then profiles would give the wrong behavior (& the debugger could cause someone to conclude invalid things about the code) - the debugger user (or profiler) could appear to reach line 3 even though j != 10. (eg: a sample profiler could record a sample at the time the speculated store was executing - recording that the program was executing line 3 at the time. A profile based optimization could then conclude that j is == 10 for that sample - this could bias optimizations incorrectly. As a debugger user you could appear to step to line 3 even though j is != 10 - confusing the user) The merge looks OK - merging the destination with the speculated code. So if they happen to all come from the same line of source code, then it's OK-ish. There's no confusion/invalid implication. -- 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 39158] wasm32: Invalid wasm generated when debuginfo is generated
https://bugs.llvm.org/show_bug.cgi?id=39158 Heejin Ahn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Heejin Ahn --- I think this is fixed by https://reviews.llvm.org/rL343827. -- 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 39185] New: MIR parser doesn't have easy way to set !IsSSA
https://bugs.llvm.org/show_bug.cgi?id=39185 Bug ID: 39185 Summary: MIR parser doesn't have easy way to set !IsSSA Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: GlobalISel Assignee: unassignedb...@nondot.org Reporter: chisophu...@gmail.com CC: llvm-bugs@lists.llvm.org Various MIR tests have a pattern like: ``` %0 = COPY $r0 %0 = COPY $r0 ; Force isSSA = false. ``` https://github.com/fuchsia-mirror/third_party-llvm/blob/70285a03596946657b49fed5ded6558050bb6e5b/test/CodeGen/AArch64/mlicm-stack-write-check.mir#L31 https://github.com/IITH-Compilers/LLVM-Loop-Profiler/blob/bdb32a89598f94808b8aae8819541eadadbcb3c2/test/CodeGen/Hexagon/expand-condsets-rm-reg.mir#L38 It would be nice if you could somehow just say `IsSSA: false` somewhere at the top of the MIR test. -- 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
