[llvm-bugs] [Bug 44555] [meta] 10.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=44555 Bug 44555 depends on bug 44652, which changed state. Bug 44652 Summary: eb0e1978df7b9e7 caused msan false positive in vectorized crc code https://bugs.llvm.org/show_bug.cgi?id=44652 What|Removed |Added Status|RESOLVED|REOPENED 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44652] eb0e1978df7b9e7 caused msan false positive in vectorized crc code
https://bugs.llvm.org/show_bug.cgi?id=44652 Simon Pilgrim changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #18 from Simon Pilgrim --- Keep open for merge into the 10.0 branch, after its been in trunk for a bit and the downstream bug is confirmed 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44529] [InstCombine] Negation not sunk through shift
https://bugs.llvm.org/show_bug.cgi?id=44529 Nikita Popov changed: What|Removed |Added Fixed By Commit(s)||0b83c5a78fae96dd66150e7a14c ||8c6d0292de01d Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Nikita Popov --- Has been fixed by https://reviews.llvm.org/D72978. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42801] [IR][PatternMatch] m_c_ICmp() should swap predicate if the match is commuted
https://bugs.llvm.org/show_bug.cgi?id=42801 Nikita Popov changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||efba7ed05e50066deaa19f741c0 ||6902a23a9c124 Resolution|--- |FIXED --- Comment #1 from Nikita Popov --- This has been addressed by https://reviews.llvm.org/D72976. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44658] Assertion failure in constrained variadic function template of class template
https://bugs.llvm.org/show_bug.cgi?id=44658 David Stone changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Stone --- I simplified my original bug too much in this bug report, so this code is apparently IFNDR. If I end up being able to reproduce the original bug (if it even is a bug), I'll open a new report -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44658] Assertion failure in constrained variadic function template of class template
https://bugs.llvm.org/show_bug.cgi?id=44658 David Stone changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #2 from David Stone --- Oops, updated wrong bug. Ignore this. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44661] Failure to partially order constrained overload set of three parameters
https://bugs.llvm.org/show_bug.cgi?id=44661 David Stone changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from David Stone --- I simplified my original bug too much in this bug report, so this code is apparently IFNDR. If I end up being able to reproduce the original bug (if it even is a bug), I'll open a new report -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44662] New: LoopAccessAnalysis's RuntimeMemoryCheckThreshold is just a bit too pessimistic?
https://bugs.llvm.org/show_bug.cgi?id=44662 Bug ID: 44662 Summary: LoopAccessAnalysis's RuntimeMemoryCheckThreshold is just a bit too pessimistic? Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Global Analyses Assignee: unassignedb...@nondot.org Reporter: lebedev...@gmail.com CC: llvm-bugs@lists.llvm.org Right now runtime-memory-check-threshold defaults to 8 (since forever: https://github.com/llvm/llvm-project/commit/1d862af7641eb88b4facce51fcf1b76c48c09d24) Unfortunately it is just 1-shy from allowing vectorization in the following wavelet recomposition code example, where we have two inputs, and one output: LV: Checking a loop in "_ZNK8rawspeed15VC5Decompressor7Wavelet15reconstructPassENS_10Array2DRefIsEENS2_IKsEES5_" from src/librawspeed/decompressors/VC5Decompressor.cpp:208:7 LV: Loop hints: force=? width=0 unroll=0 LV: Found a loop: for.inc24 LV: Found an induction variable. LV: We can vectorize this loop (with a runtime bound check)! LV: Found trip count: 0 LV: The Smallest and Widest types: 16 / 16 bits. LV: The Widest register safe to use is: 256 bits. LV: Found uniform instruction: %cmp18 = icmp ult i64 %indvars.iv.next196, %34, !dbg !172 LV: Found uniform instruction: %arrayidx.i.i.i.i83 = getelementptr inbounds i16, i16* %arrayidx.i.i1.i.i.i, i64 %indvars.iv195, !dbg !145 LV: Found uniform instruction: %arrayidx.i.i11.i.i.i.i = getelementptr inbounds i16, i16* %arrayidx.i.i.i.i.i.i.i85, i64 %idxprom.i.i.i.i.i.i.i, !dbg !148 LV: Found uniform instruction: %arrayidx.i.i11.1.i.i.i.i87 = getelementptr inbounds i16, i16* %arrayidx.i.i.i.i.i.i.i85, i64 %33, !dbg !148 LV: Found uniform instruction: %arrayidx.i.i11.2.i.i.i.i90 = getelementptr inbounds i16, i16* %arrayidx.i.i.i.i.i.i.i85, i64 %idxprom.i.i.i.2.i.i.i.i, !dbg !148 LV: Found uniform instruction: %arrayidx.i25.i = getelementptr inbounds i16, i16* %arrayidx.i.i23.i, i64 %indvars.iv195, !dbg !166 LV: Found uniform instruction: %arrayidx.i.i100 = getelementptr inbounds i16, i16* %arrayidx.i.i.i99, i64 %indvars.iv195, !dbg !169 LV: Found uniform instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found uniform instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found uniform instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found uniform instruction: %indvars.iv195 = phi i64 [ 0, %for.inc24.lr.ph ], [ %indvars.iv.next196, %for.inc24 ] LV: Found uniform instruction: %indvars.iv.next196 = add nuw nsw i64 %indvars.iv195, 1, !dbg !171 LV: Found scalar instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found scalar instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found scalar instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found scalar instruction: %indvars.iv195 = phi i64 [ 0, %for.inc24.lr.ph ], [ %indvars.iv.next196, %for.inc24 ] LV: Found scalar instruction: %indvars.iv.next196 = add nuw nsw i64 %indvars.iv195, 1, !dbg !171 LV: Found uniform instruction: %cmp18 = icmp ult i64 %indvars.iv.next196, %34, !dbg !172 LV: Found uniform instruction: %arrayidx.i.i.i.i83 = getelementptr inbounds i16, i16* %arrayidx.i.i1.i.i.i, i64 %indvars.iv195, !dbg !145 LV: Found uniform instruction: %arrayidx.i.i11.i.i.i.i = getelementptr inbounds i16, i16* %arrayidx.i.i.i.i.i.i.i85, i64 %idxprom.i.i.i.i.i.i.i, !dbg !148 LV: Found uniform instruction: %arrayidx.i.i11.1.i.i.i.i87 = getelementptr inbounds i16, i16* %arrayidx.i.i.i.i.i.i.i85, i64 %33, !dbg !148 LV: Found uniform instruction: %arrayidx.i.i11.2.i.i.i.i90 = getelementptr inbounds i16, i16* %arrayidx.i.i.i.i.i.i.i85, i64 %idxprom.i.i.i.2.i.i.i.i, !dbg !148 LV: Found uniform instruction: %arrayidx.i25.i = getelementptr inbounds i16, i16* %arrayidx.i.i23.i, i64 %indvars.iv195, !dbg !166 LV: Found uniform instruction: %arrayidx.i.i100 = getelementptr inbounds i16, i16* %arrayidx.i.i.i99, i64 %indvars.iv195, !dbg !169 LV: Found uniform instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found uniform instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i16* %process.sroa.6148.0.copyload, i64 %indvars.iv195, !dbg !147 LV: Found uniform instruction: %arrayidx.i.i.i.i.i.i.i85 = getelementptr inbounds i16, i
[llvm-bugs] [Bug 44663] New: [Attributor?] Smart noalias deduction
https://bugs.llvm.org/show_bug.cgi?id=44663
Bug ID: 44663
Summary: [Attributor?] Smart noalias deduction
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Global Analyses
Assignee: unassignedb...@nondot.org
Reporter: lebedev...@gmail.com
CC: llvm-bugs@lists.llvm.org
In this example `sink()` is static, we know all it's call sites.
We should be able to tell in all the call sites,
it's third argument (`highpass.data`) does not alias
with any other pointers used in `sink()` (namely `highhigh.data` and
`lowhigh.data`),
because we should be able to see how `highpass.data`
is being set to a fresh noalias pointer.
https://godbolt.org/z/32edkj
#include // for assert
#include
#include // for vector
#include // for vector
#include // for vector
template class Array2DRef {
int _pitch = 0;
T* _data = nullptr;
friend Array2DRef; // We need to be able to convert to const
version.
inline T& operator[](int row) const;
public:
using value_type = T;
using cvless_value_type = typename std::remove_cv::type;
int width = 0, height = 0;
Array2DRef() = default;
Array2DRef(T* data, int dataWidth, int dataHeight, int dataPitch = 0);
// Conversion from Array2DRef to Array2DRef.
template ::type, T2>::value>>
Array2DRef(Array2DRef RHS) { // NOLINT google-explicit-constructor
_data = RHS._data;
_pitch = RHS._pitch;
width = RHS.width;
height = RHS.height;
}
template ::allocator_type>
static Array2DRef
create(std::vector* storage, int width,
int height) {
storage->resize(width * height);
return {storage->data(), width, height};
}
inline T& operator()(int row, int col) const;
};
template
Array2DRef::Array2DRef(T* data, const int dataWidth, const int dataHeight,
const int dataPitch /* = 0 */)
: _data(data), width(dataWidth), height(dataHeight) {
assert(width >= 0);
assert(height >= 0);
_pitch = (dataPitch == 0 ? dataWidth : dataPitch);
}
template T& Array2DRef::operator[](const int row) const {
assert(_data);
assert(row >= 0);
assert(row < height);
return _data[row * _pitch];
}
template
T& Array2DRef::operator()(const int row, const int col) const {
assert(col >= 0);
assert(col < width);
return (&(operator[](row)))[col];
}
static __attribute__((noinline)) void sink(const Array2DRef
highhigh, const Array2DRef lowhigh, Array2DRef
highpass) {
for(int row = 0; row < highpass.height; ++row) {
for(int col = 0; col < highpass.width; ++col) {
// highpass does not alias highhigh/lowhigh !
// this should nicely vectorize.
highpass(row, col) = 24 * highhigh(row, col) + 18 * lowhigh (row,
col);
}
}
}
void foo(int width, int height, const Array2DRef highhigh, const
Array2DRef lowhigh, std::vector& highpass_storage) {
Array2DRef highpass = Array2DRef::create(&highpass_storage,
width, height);
sink(highhigh, lowhigh, highpass);
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44664] New: Mention libsanitizer
https://bugs.llvm.org/show_bug.cgi?id=44664 Bug ID: 44664 Summary: Mention libsanitizer Product: Bugzilla Admin Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Products Assignee: unassignedb...@nondot.org Reporter: roland.il...@gmx.de CC: kristof.be...@gmail.com, llvm-bugs@lists.llvm.org, r...@google.com, t.p.northo...@gmail.com I reported a libsanitizer bug against GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93433 I was redirected here to report this bug in libsanitizer. I expected that I would find the text "sanit" somewhere on the projects page https://bugs.llvm.org/enter_bug.cgi, but I didn't find anything related. It would be more helpful if I could just type in a few words, and the correct product and its component would be suggested automatically. Or if the overview page would have some more keywords. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44665] New: sanitizer_linux.cc contains non-Linux-specific code
https://bugs.llvm.org/show_bug.cgi?id=44665 Bug ID: 44665 Summary: sanitizer_linux.cc contains non-Linux-specific code Product: new-bugs Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: roland.il...@gmx.de CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org The file sanitizer_linux.cc contains these lines: > // This file is shared between AddressSanitizer and ThreadSanitizer > // run-time libraries and implements linux-specific functions from > // sanitizer_libc.h. > //===--===// > > #include "sanitizer_platform.h" > > #if SANITIZER_FREEBSD || SANITIZER_LINUX || SANITIZER_NETBSD || \ > SANITIZER_OPENBSD || SANITIZER_SOLARIS These lines are obviously not specific to Linux. The file should be renamed in order to match its content. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 41050] powerpc64 exceptions: code sequence calling __cxa_begin_catch is missing "ld r2, 40(r1)"
https://bugs.llvm.org/show_bug.cgi?id=41050 Mark Millard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #46 from Mark Millard --- FreeBSD has officially switched head for powerpc64 over to llvm/clang 9.0.1 based. So the fix is confirmed in standard builds for the context, not just special ones. The fix had been in use during the development of the switch over from gcc 4.2.1 and so has a fair amount of history at this point as well. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 25780] [META] Using Clang as the FreeBSD/ppc system compiler
https://bugs.llvm.org/show_bug.cgi?id=25780 Bug 25780 depends on bug 26844, which changed state. Bug 26844 Summary: __builtin_eh_return is not fully implemented for PPC nor PPC64: no DW_CFA_offset output for scratch registers( r3-r6) [still true of 8.0.0] https://bugs.llvm.org/show_bug.cgi?id=26844 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26844] __builtin_eh_return is not fully implemented for PPC nor PPC64: no DW_CFA_offset output for scratch registers( r3-r6) [still true of 8.0.0]
https://bugs.llvm.org/show_bug.cgi?id=26844 Mark Millard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #18 from Mark Millard --- FreeBSD head (13) is now llvm/clang 9.0.1 based and looking at what it produces for powerpc64 shows that: g++9 has r3-r6 scratch register information in the with_unwind_init_save_restore and with_unwind_init_and_eh_return_save_restore example code, even when based on FreeBSD headers and libraries: g++9 -std=c++17 -std=c++17 -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s -o normal_and_special_save_restore.gcc normal_and_special_save_restore.cpp leads to, for example, normal_and_special_save_restore.gcc having: <5><0x1c6c:0x1d04><> 0x1c6c: 0x1c70: 0x1c84: 0x1ca0: 0x1cc0: . . . C++ (clang++) does not have any r3, r4, r5, or r6 (scratch register) information in its dwarf information for the example. However, with the use of llvm's libunwind instead of the old library code in head for powerpc64, the access(es) that expected to find scratch register descriptions do not happen and there is no SIGSEGV. So, if there is some sort of problem here now, such as a clang vs. gcc ABI mismatch that prevents using one of the compilers, it is a different problem than was originally being reported as far as FeeBSD is concerned. (The original technical detail is still true but the library context changed.) So a form of "overcome by events". As far as I can tell INVALID is the best-fit for the status, so that is what I'm selecting. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 31590] FreeBSD clang 3.91 TARGET_ARCH=powerpc64 context: clang 3.9.1 can not compile/assemble the likes of llvm/projects/libunwind/src/UnwindRegistersSave.S
https://bugs.llvm.org/show_bug.cgi?id=31590 Mark Millard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Mark Millard --- FreeBSD head (13) has switched powerpc64 to clang+lld (9.0.1) and is using clang for 32-bit powerpc as well. LIBUNWIND now builds fine, with no errors like were reported here. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43350] [PowerPC32] segmentation fault on C++ exception handling
https://bugs.llvm.org/show_bug.cgi?id=43350 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassignedb...@nondot.org |i...@maskray.me Status|NEW |RESOLVED --- Comment #8 from Fangrui Song --- Fixed by https://reviews.llvm.org/D73399 . Will be included in lld 10. Tested by Bdragon. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38074] Error static linking when clang++/lld 6.0.0 using Arch Linux
https://bugs.llvm.org/show_bug.cgi?id=38074 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED CC||i...@maskray.me -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 44666] New: Assertion failure when using concepts combined with variadic templates and overload resolution
https://bugs.llvm.org/show_bug.cgi?id=44666
Bug ID: 44666
Summary: Assertion failure when using concepts combined with
variadic templates and overload resolution
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: da...@doublewise.net
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following code (sorry I could not reduce it more)
```
template
concept constructible_from = requires { T(Args()...); };
template
constexpr bool true_ = true;
template
concept convertible_to = constructible_from and true_;
template
concept copy_constructible = requires(T value) { T(value); };
template requires (... and copy_constructible)
int f();
template
struct s {
template requires convertible_to
s(s const & other);
template requires constructible_from
s(s const & other);
};
auto x = f>();
```
when compiled with `clang++ -std=c++2a -o /dev/null -c main.cpp`
crashes with
```
clang++: /home/david/llvm/clang/lib/Sema/SemaTemplateInstantiate.cpp:1179:
clang::TemplateArgument getPackSubstitutedTemplateArgument(clang::Sema &,
clang::TemplateArgument): Assertion `S.ArgumentPackSubstitutionIndex <
(int)Arg.pack_size()' failed.
Stack dump:
0. Program arguments: /home/david/llvm/build/bin/clang++ -std=c++2a -o
/dev/null -c main.cpp
1. main.cpp:24:25: current parser token ')'
#0 0x5616c953b542 PrintStackTraceSignalHandler(void*)
(/home/david/llvm/build/bin/clang+++0x31f2542)
#1 0x5616c9538eae llvm::sys::RunSignalHandlers()
(/home/david/llvm/build/bin/clang+++0x31efeae)
#2 0x5616c953a5c7 llvm::sys::CleanupOnSignal(unsigned long)
(/home/david/llvm/build/bin/clang+++0x31f15c7)
#3 0x5616c94b57be (anonymous
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long)
(/home/david/llvm/build/bin/clang+++0x316c7be)
#4 0x5616c94b5964 CrashRecoverySignalHandler(int)
(/home/david/llvm/build/bin/clang+++0x316c964)
#5 0x7fd7d4df7930 __restore_rt (/usr/lib/libpthread.so.0+0x14930)
#6 0x7fd7d4872f25 raise (/usr/lib/libc.so.6+0x3bf25)
#7 0x7fd7d485c897 abort (/usr/lib/libc.so.6+0x25897)
#8 0x7fd7d485c767 _nl_load_domain.cold (/usr/lib/libc.so.6+0x25767) #9
0x7fd7d486b526 (/usr/lib/libc.so.6+0x34526)
#10 0x5616cb8e5406 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeLocBuilder&,
clang::TypeLoc) (/home/david/llvm/build/bin/clang+++0x559c406)
#11 0x5616cb8df7aa clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformType(clang::TypeSourceInfo*)
(/home/david/llvm/build/bin/clang+++0x55967aa)
#12 0x5616cb9062ec clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformTemplateArgument(clang::TemplateArgumentLoc
const&, clang::TemplateArgumentLoc&, bool)
(/home/david/llvm/build/bin/clang+++0x55bd2ec)
#13 0x5616cb8eefd5 bool clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformTemplateArguments(clang::TemplateArgumentLoc const*, clang::TemplateArgumentLoc const*,
clang::TemplateArgumentListInfo&, bool)
(/home/david/llvm/build/bin/clang+++0x55a5fd5)
#14 0x5616cb8eece3
clang::Sema::SubstTemplateArguments(llvm::ArrayRef,
clang::MultiLevelTemplateArgumentList const&, clang::TemplateArgumentListInfo&)
(/home/david/llvm/build/bin/clang+++0x55a5ce3)
#15 0x5616cb299cb3 substituteParameterMappings(clang::Sema&,
clang::NormalizedConstraint&, clang::ConceptDecl*,
llvm::ArrayRef, clang::ASTTemplateArgumentListInfo
const*) (/home/david/llvm/build/bin/clang+++0x4f50cb3)
#16 0x5616cb29932b
clang::NormalizedConstraint::fromConstraintExpr(clang::Sema&,
clang::NamedDecl*, clang::Expr const*)
(/home/david/llvm/build/bin/clang+++0x4f5032b)
#17 0x5616cb298e81
clang::NormalizedConstraint::fromConstraintExprs(clang::Sema&,
clang::NamedDecl*, llvm::ArrayRef)
(/home/david/llvm/build/bin/clang+++0x4f4fe81)
#18 0x5616cb298d6d
clang::Sema::getNormalizedAssociatedConstraints(clang::NamedDecl*,
llvm::ArrayRef)
(/home/david/llvm/build/bin/clang+++0x4f4fd6d)
#19 0x5616cb299f63 clang::Sema::IsAtLeastAsConstrained(clang::NamedDecl*,
llvm::ArrayRef, clang::NamedDecl*,
llvm::ArrayRef, bool&)
(/home/david/llvm/build/bin/clang+++0x4f50f63)
#20 0x5616cb88c19e
clang::Sema::getMoreSpecializedTemplate(clang::FunctionTemplateDecl*,
clang::FunctionTemplateDecl*, clang::SourceLocation,
clang::TemplatePartialOrderingContext, unsigned int, unsigned
int)::$_5::operator()() const (/home/david/llvm/build/bin/clang+++0x554319e)
#21 0x5616cb88b844
clang::Sema::getMoreSpecializedTemplate(clang::FunctionTemplateDecl*,
clang::FunctionTemplateDecl*, clang::SourceLocation,
clang::TemplatePa
[llvm-bugs] [Bug 44657] Rejects valid code with requires clause accepting bool expression on copy / move
https://bugs.llvm.org/show_bug.cgi?id=44657 David Stone changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from David Stone --- Resolved on master -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
