[llvm-bugs] Issue 36939 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-08-07 Type: Bug New issue 36939 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36939 Detailed Report: https://oss-fuzz.com/testcase?key=5434976161103872 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: isa(Val) && "cast() argument of incompatible type!" llvm::MachineFunction::addLandingPad llvm::SelectionDAGISel::PrepareEHLandingPad Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202011180625 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5434976161103872 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 36941 in oss-fuzz: llvm:llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevl...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigch...@gmail.com, eney...@google.com, llvm-...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitch...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2021-08-07 Type: Bug New issue 36941 by ClusterFuzz-External: llvm:llvm-isel-fuzzer--aarch64-O2: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36941 Detailed Report: https://oss-fuzz.com/testcase?key=4990035324698624 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-isel-fuzzer--aarch64-O2 Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0539374e Crash State: llvm::llvm_unreachable_internal isTopLevelPadForMSVC llvm::calculateSEHStateNumbers Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202011180625 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4990035324698624 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51315] [InstCombine] Failure to drop sext before bitcast-icmp
https://bugs.llvm.org/show_bug.cgi?id=51315 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||0369714b3168 -- 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 51399] New: Failed to compile expression with constant operator=()
https://bugs.llvm.org/show_bug.cgi?id=51399 Bug ID: 51399 Summary: Failed to compile expression with constant operator=() Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: C++17 Assignee: unassignedclangb...@nondot.org Reporter: denismikhaylo...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk The following simple code that works on gcc(and msvc too) will not compile with clang: https://godbolt.org/z/zE54xa1rP What's interesting: 1. This works good when i replace operator= to operator+ or some other operator 2. This also works good when i wrap expression name="degrees" into parentheses, for example: field_t<(name="degrees")> degrees; -- 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 51400] New: std::string + -finstrument-functions + -std=c++20 = template miscompilation
https://bugs.llvm.org/show_bug.cgi?id=51400 Bug ID: 51400 Summary: std::string + -finstrument-functions + -std=c++20 = template miscompilation Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: mattf53...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 25117 --> https://bugs.llvm.org/attachment.cgi?id=25117&action=edit MRE and test script When compiling with `-finstrument-functions` and any standard above C++17, that is C++2a aka 20 or 2b aka 23, when attempting to declare a string, the proper templates relating to standard library allocators are not included in the object files, leading to the following linker error: ``` /usr/bin/ld: /tmp/main-6f2635.o: in function `std::allocator_traits >::deallocate(std::allocator&, char*, unsigned long)': main.cpp:(.text._ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm[_ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm]+0x5d): undefined reference to `std::allocator::deallocate(char*, unsigned long)' /usr/bin/ld: main.cpp:(.text._ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm[_ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm]+0x99): undefined reference to `std::allocator::deallocate(char*, unsigned long)' clang-14: error: linker command failed with exit code 1 (use -v to see invocation) ``` Additionally, if the string has contents, the error will include the inability to find an allocate method: ``` /usr/bin/ld: /tmp/main-248bd2.o: in function `std::allocator_traits >::deallocate(std::allocator&, char*, unsigned long)': main.cpp:(.text._ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm[_ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm]+0x5d): undefined reference to `std::allocator::deallocate(char*, unsigned long)' /usr/bin/ld: main.cpp:(.text._ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm[_ZNSt16allocator_traitsISaIcEE10deallocateERS0_Pcm]+0x99): undefined reference to `std::allocator::deallocate(char*, unsigned long)' /usr/bin/ld: /tmp/main-248bd2.o: in function `std::allocator_traits >::allocate(std::allocator&, unsigned long)': main.cpp:(.text._ZNSt16allocator_traitsISaIcEE8allocateERS0_m[_ZNSt16allocator_traitsISaIcEE8allocateERS0_m]+0x49): undefined reference to `std::allocator::allocate(unsigned long)' /usr/bin/ld: main.cpp:(.text._ZNSt16allocator_traitsISaIcEE8allocateERS0_m[_ZNSt16allocator_traitsISaIcEE8allocateERS0_m]+0x81): undefined reference to `std::allocator::allocate(unsigned long)' clang-14: error: linker command failed with exit code 1 (use -v to see invocation) ``` This manifests for `-std=c++20`, `-std=gnu++20`, `-std=c++2b`, `-std=gnu++2b`, but not for `std=c++17`. Additionally, the g++ can compile the code with the same flags, for every C++ standard I tested, from c++17 to c++2b. See attached tarball for a minimal reproducible example and a script to test whether clang++ and g++ can build it for each standard. I wasn't sure if this qualifies as release blocker because theoretically you could remove -finstrument-functions, in which case it compiles just fine. However I like seeing all the function names in debugging tools like ASAN. -- 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 51401] New: Various problems with CTAD and disignated initialisers
https://bugs.llvm.org/show_bug.cgi?id=51401
Bug ID: 51401
Summary: Various problems with CTAD and disignated initialisers
Product: clang
Version: 12.0
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: h2+b...@fsfe.org
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
All the code below builds with GCC>=10 and -std=c++20.
All except the two marked examples also build with MSVC.
Everything after "Outer2 o22" fails with Clang.
```c++
struct Inner
{
int i = 0;
};
struct Outer1
{
Inner s{};
};
template
struct Outer2
{
Inner s{};
};
template
struct Outer3
{
T s{};
};
int main()
{
Outer1 o1{};
Outer1 o2{{}};
Outer1 o3{Inner{}};
Outer1 o4{Inner{1}};
Outer1 o5{.s = Inner{}};
Outer1 o6{.s = Inner{ .i = 1}};
Outer2 o21{};
Outer2 o22{{}};
Outer2 o23{Inner{}};// fails in MSVC
Outer2 o24{Inner{1}}; // fails in MSVC
Outer2 o25{.s = Inner{}};
Outer2 o26{.s = Inner{ .i = 1}};
Outer3 o33{Inner{}};
Outer3 o34{Inner{1}};
Outer3 o35{.s = Inner{}};
Outer3 o36{.s = Inner{ .i = 1}};
}
```
--
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 51402] New: Incomplete type allowed for returned brace initialized unique_ptr
https://bugs.llvm.org/show_bug.cgi?id=51402
Bug ID: 51402
Summary: Incomplete type allowed for returned brace initialized
unique_ptr
Product: clang
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: ammi...@hotmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I've checked previous versions and seems it's not a regression.
Returning unique_ptr{} vs {} (which should be equivalent)
either compiles or not. Trying to assign that returnred value actually triggers
a compilation error, too.
https://godbolt.org/z/qer8eczhx
#include
struct incomplete;
std::unique_ptr u()
{
return {}; //this compiles
// return std::unique_ptr{};// this one gives an error
}
int main(int, char*[])
{
// auto x=u(); // this also gives compilation error
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
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 33930 in oss-fuzz: llvm:clang-objc-fuzzer: Stack-overflow in llvm::FoldingSetNodeID::operator==
Updates: Status: WontFix Comment #1 on issue 33930 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Stack-overflow in llvm::FoldingSetNodeID::operator== https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33930#c1 ClusterFuzz testcase 4647297309868032 is closed as invalid, so closing issue. -- 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51403] New: [openmp] runtime/test/affinity/Output/redetect.c test hangs
https://bugs.llvm.org/show_bug.cgi?id=51403
Bug ID: 51403
Summary: [openmp] runtime/test/affinity/Output/redetect.c test
hangs
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: mgo...@gentoo.org
CC: jonathan.l.pey...@intel.com, llvm-bugs@lists.llvm.org
Blocks: 51236
I can reliably reproduce this when building with GCC 11.2.0 and Clang
13.0.0-rc1, both when building with -O2 and -O0 -g.
This is on Linux 5.13.8, glibc 2.33, openmp release/13.x branch.
If I'm reading the backtraces right, it seems that the first thread is in
wait(), while all the remaining threads are waiting on a futex.
Process 3138661 stopped
* thread #1, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd256015d57 libc.so.6`__GI___wait4(pid=-1,
stat_loc=0x7ffe95b5fbcc, options=0, usage=0x) at
wait4.c:30:10
thread #2, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017e45a8,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #3, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017e73ac,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #4, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017ea168,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #5, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017ecf6c,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #6, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017efd6c,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #7, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017f2b6c,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #8, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017f5928,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #9, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017f8728,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #10, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017fb528,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #11, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x017fe328,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
thread #12, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
frame #0: 0x7fd25612a6c2
libpthread.so.0`__futex_abstimed_wait_common64(futex_word=0x018010e8,
expected=0, clockid=, abstime=0x,
private=, cancel=) at futex-internal.c:74:11
Executable module set to
"/tmp/portage/sys-libs/libomp-13.0.0./work/libomp-13.0.0._build-abi_x86_64.amd64/runtime/test/affinity/Output/redetect.c.tmp".
(lldb) bt
error: libc.so.6 {0x5c83}: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x42)
attribute, but range extraction failed (invalid range list offset 0x42), please
file a bug and attach the file at the start of this error message
error: libc.so.6 {0x5e0f}: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x37)
attribute, but range extraction failed (invalid range list offset 0x37), please
file a bug and attach the file at the start of this error message
* thread #1, name = 'redetect.c.tmp', stop reason = signal SIGSTOP
* frame #0: 0x7fd256015d57 libc.so.6`__GI___wait4(pid=-1,
stat_loc=0x7ffe95b5fbcc, options=0, usage=0x) at
wait4.c:30:10
frame #1: 0x00
[llvm-bugs] [Bug 51404] New: 'Clang :: Driver/rocm-detect.hip' fails on Gentoo
https://bugs.llvm.org/show_bug.cgi?id=51404
Bug ID: 51404
Summary: 'Clang :: Driver/rocm-detect.hip' fails on Gentoo
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: mgo...@gentoo.org
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk,
yaxun@amd.com
Blocks: 51236
If I'm not mistaken, the test fails due to hardcoding bad assumptions about
clang's resource dir.
Our resource dir is specified as:
-DCLANG_RESOURCE_DIR="../../../../lib/clang/${clang_version}"
The relevant FileCheck output is:
+ : 'RUN: at line 44'
+ /usr/lib/llvm/13/bin/FileCheck -check-prefixes=SPACK
/var/tmp/portage/sys-devel/clang-13.0.0./work/clang/test/Driver/rocm-detect.hip
+
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86/test/Driver/Output/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin/clang
-### -v -target x86_64-linux-gnu --cuda-gpu-arch=gfx900
--print-rocm-search-dirs
/var/tmp/portage/sys-devel/clang-13.0.0./work/clang/test/Driver/rocm-detect.hip
/var/tmp/portage/sys-devel/clang-13.0.0./work/clang/test/Driver/rocm-detect.hip:86:11:
error: SPACK: expected string not found in input
// SPACK: ROCm installation search path:
[[CLANG]]/{{(llvm/)?}}lib{{[0-9]*}}/clang/{{[0-9.]+}}
^
:3:187: note: scanning from here
ROCm installation search path:
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86/test/Driver/Output/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z
^
:3:187: note: with "CLANG" equal to
"/var/tmp/portage/sys-devel/clang-13\\.0\\.0\\./work/x/y/clang-abi_x86_32\\.x86"
ROCm installation search path:
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86/test/Driver/Output/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z
^
:4:1: note: possible intended match here
ROCm installation search path:
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86
^
Input file:
Check file:
/var/tmp/portage/sys-devel/clang-13.0.0./work/clang/test/Driver/rocm-detect.hip
-dump-input=help explains the following input dump.
Input was:
<<
1: ROCm installation search path (Spack 4.0.0):
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86/test/Driver/Output/rocm-spack
2: ROCm installation search path:
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86
3: ROCm installation search path:
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86/test/Driver/Output/rocm-spack/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z
check:86'0
X error: no match found
check:86'1
with "CLANG" equal to
"/var/tmp/portage/sys-devel/clang-13\\.0\\.0\\./work/x/y/clang-abi_x86_32\\.x86"
4: ROCm installation search path:
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86
check:86'0
~~
check:86'2 ?
possible intended match
5: ROCm installation search path:
/var/tmp/portage/sys-devel/clang-13.0.0./work/x/y/clang-abi_x86_32.x86/bin/../../../../lib/clang/13.0.0
check:86'0
~~~
6: ROCm installation search path: /opt/rocm
check:86'0 ~
7: clang version 13.0.0
check:86'0 ~
8: Target: x86_64-unknown-linux-gnu
check:86'0 ~
9: Thread model: posix
check:86'0
.
.
.
>>
Re
[llvm-bugs] [Bug 51405] New: dockerfiles and related scripts are out of date
https://bugs.llvm.org/show_bug.cgi?id=51405 Bug ID: 51405 Summary: dockerfiles and related scripts are out of date Product: new-bugs Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: uncomple...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org The dockerfiles in llvm/utils/docker are out of date. Among other things they are: - Still using SVN - Cmake version is outdated - GCC version is outdated - probably more... I've already begun updating them. One issue I see already is in maintaining the ability to apply multiple patches to the source in the correct order given the fact that git patch UUIDs are not monotonically increasing. I've seen something about this in LLVMs documentation so I think it's doable anyway. -- 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 51406] New: Constraint normalization of a parenthesized atomic constraint yields a different expression than an identical non-parenthesized atomic constraint
https://bugs.llvm.org/show_bug.cgi?id=51406
Bug ID: 51406
Summary: Constraint normalization of a parenthesized atomic
constraint yields a different expression than an
identical non-parenthesized atomic constraint
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: matthewjbariche...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Affected versions:
- trunk
- 12.0.1
- 12.0.0
- 11.0.1
- 11.0.0
- 10.0.1
- 10.0.0
- 9.0.1
- 9.0.0
Driver cmdline:
Note: For versions not supporting -std=c++20, -std=c++2a was used.
clang++ -std=c++20 -Werror -Wall -pedantic
Code:
template
concept B = true;
template
requires (B)
struct A;
template
requires B
struct A {};
Error:
:9:10: error: requires clause differs in template redeclaration
requires B
^
:5:10: note: previous template declaration is here
requires (B)
^
1 error generated.
Notice that in the example the forward declaration of the template `A` has a
requires clause with a parenthesized atomic constraint, `(B)`, whereas the
definition of `A` has the same requires clause, albeit non-parenthesized.
After constraint normalization, both requires clauses should be equivalent,
however, clang yields an error.
Notes:
- GCC does not exhibit this issue.
- MSVC has a similar issue that seems to be, incorrectly, fixed by converting
the redeclaration of `A` into a partially specialized template.
--
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
