[llvm-bugs] [Bug 45204] New: concepts: constrained member functions illegally instantiated during explicit class template instantiation
https://bugs.llvm.org/show_bug.cgi?id=45204
Bug ID: 45204
Summary: concepts: constrained member functions illegally
instantiated during explicit class template
instantiation
Product: clang
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: akrze...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
The following correct C++20 program fails to compile in clang.
```
template
concept has_a = requires(T v) { v.a(); };
template
struct X
{
void fun(T) {}
void gun(T v) requires has_a { v.a(); }
};
template struct X;
```
member function `gun()` is instantiated which is a bug according to
http://eel.is/c++draft/temp.explicit#11
This works in the old experimental implementation of concepts in Clang by Saar
Raz: https://godbolt.org/z/K4SaCm
--
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 45205] New: libcxx string optimization breaks tblgen on POWER
https://bugs.llvm.org/show_bug.cgi?id=45205 Bug ID: 45205 Summary: libcxx string optimization breaks tblgen on POWER Product: libc++ Version: 10.0 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: w1rpujqxs5d0srw18wks6ez4hko...@cmx.ietfng.org CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com a8a9c8e0a11abc9ed4ed78fed528334371fedf87 / D72160 causes a LLVM built on my Power9 build box to fail to be able to compile itself. tblgen bails with cd /cheri/build/llvm-project-build && /cheri/build/llvm-project-build/bin/clang-tblgen -gen-clang-diags-defs -clang-component=Refactoring -I /cheri/source/llvm-project/clang/include -I /cheri/source/llvm-project/clang/include/clang/Basic -I /cheri/source/llvm-pro ject/llvm/include /cheri/source/llvm-project/clang/include/clang/Basic/Diagnostic.td --write-if-changed -o tools/clang/include/clang/Basic/DiagnosticRefactoringKinds.inc -d tools/clang/include/clang/Basic/DiagnosticRefactoringKinds.inc.d realloc(): invalid next size #0 0x10186410 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /cheri/source/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x10186410 PrintStackTraceSignalHandler(void*) /cheri/source/llvm-project/llvm/lib/Support/Unix/Signals.inc:656:3 #2 0x10183498 llvm::sys::RunSignalHandlers() /cheri/source/llvm-project/llvm/lib/Support/Signals.cpp:67:5 #3 0x10186c84 SignalHandler(int) /cheri/source/llvm-project/llvm/lib/Support/Unix/Signals.inc:396:3 #4 0x7fff8ee704d8 (linux-vdso64.so.1+0x4d8) #5 0x7fff8e8259c8 __libc_signal_restore_set /build/glibc-hxXnX3/glibc-2.29/signal/../sysdeps/unix/sysv/linux/internal-signals.h:84:10 #6 0x7fff8e8259c8 raise /build/glibc-hxXnX3/glibc-2.29/signal/../sysdeps/unix/sysv/linux/raise.c:48:3 #7 0x7fff8e807c8c abort /build/glibc-hxXnX3/glibc-2.29/stdlib/abort.c:79:7 #8 0x7fff8e870c7c __libc_message /build/glibc-hxXnX3/glibc-2.29/libio/../sysdeps/posix/libc_fatal.c:181:7 #9 0x7fff8e87a408 malloc_printerr /build/glibc-hxXnX3/glibc-2.29/malloc/malloc.c:5366:3 #10 0x7fff8e87f6ac _int_realloc /build/glibc-hxXnX3/glibc-2.29/malloc/malloc.c:4576:5 #11 0x7fff8e880bc8 realloc /build/glibc-hxXnX3/glibc-2.29/malloc/malloc.c:3230:7 #12 0x1013d234 llvm::SmallVectorBase::grow_pod(void*, unsigned long, unsigned long) /cheri/source/llvm-project/llvm/include/llvm/Support/MemAlloc.h:53:18 #13 0x101ca198 llvm::SmallVectorTemplateCommon::grow_pod(unsigned long, unsigned long) /cheri/source/llvm-project/llvm/include/llvm/ADT/SmallVector.h:100:22 #14 0x101ca198 llvm::SmallVectorTemplateBase::grow(unsigned long) /cheri/source/llvm-project/llvm/include/llvm/ADT/SmallVector.h:301:41 #15 0x101ca198 llvm::SmallVectorTemplateBase::push_back(llvm::RecordVal const&) /cheri/source/llvm-project/llvm/include/llvm/ADT/SmallVector.h:306:13 #16 0x101ca198 llvm::Record::addValue(llvm::RecordVal const&) /cheri/source/llvm-project/llvm/include/llvm/TableGen/Record.h:1547:12 #17 0x101ca198 llvm::TGParser::AddValue(llvm::Record*, llvm::SMLoc, llvm::RecordVal const&) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:152:13 #18 0x101cb044 llvm::TGParser::AddSubClass(llvm::Record*, llvm::SubClassReference&) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:232:9 #19 0x101d80ec llvm::TGParser::ParseObjectBody(llvm::Record*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:2730:11 #20 0x101d83a0 llvm::TGParser::ParseDef(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:2767:7 #21 0x101d8f40 llvm::TGParser::ParseObject(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:3399:29 #22 0x101da5ec llvm::TGParser::ParseObjectList(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:3426:9 #23 0x101da5ec llvm::TGParser::ParseTopLevelLet(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:3143:9 #24 0x101d8f64 llvm::TGParser::ParseObject(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:3398:29 #25 0x101da5ec llvm::TGParser::ParseObjectList(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:3426:9 #26 0x101da5ec llvm::TGParser::ParseTopLevelLet(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:3143:9 #27 0x101d8f64 llvm::TGParser::ParseObject(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGParser.cpp:3398:29 #28 0x101dc08c llvm::TGParser::ParseObjectList(llvm::MultiClass*) /cheri/source/llvm-project/llvm/lib/TableGen/TGPars
[llvm-bugs] [Bug 45206] New: Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"), function ~ScopedHashTableScope, file include/llvm/ADT/ScopedHashTable.h, line 2
https://bugs.llvm.org/show_bug.cgi?id=45206 Bug ID: 45206 Summary: Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"), function ~ScopedHashTableScope, file include/llvm/ADT/ScopedHashTable.h, line 245. Product: libraries Version: 10.0 Hardware: Other OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: Core LLVM classes Assignee: unassignedb...@nondot.org Reporter: pku...@anongoth.pl CC: llvm-bugs@lists.llvm.org Created attachment 23231 --> https://bugs.llvm.org/attachment.cgi?id=23231&action=edit bug reproduction files I use FreeBSD head on powerpc64 with LLVM 10 rc3. Compiling math/gsl port fails with: /bin/sh ../libtool --tag=CC--mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I..-O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c -o cgbmv.lo cgbmv.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c cgbmv.c -fPIC -DPIC -o .libs/cgbmv.o Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"), function ~ScopedHashTableScope, file /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h, line 245. Stack dump: 0. Program arguments: cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c cgbmv.c -fPIC -DPIC -o .libs/cgbmv.o 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module 'cgbmv.c'. 4. Running pass 'Early CSE' on function '@cblas_cgbmv' #0 0x13bac208 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13 #1 0x13ba98d0 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:67:5 #2 0x13baf278 HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:75:7 #3 0x13baf4ec CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51 #4 0x000815732748 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:303:3 cc: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 10.0.0 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.0-rc3-1-gc290cb61fdc) Target: powerpc64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin Files for reproducing this issue are attached. -- 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 45207] New: Crash on invalid recursive variadic template struct definition
https://bugs.llvm.org/show_bug.cgi?id=45207
Bug ID: 45207
Summary: Crash on invalid recursive variadic template struct
definition
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: release blocker
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: ryan_greenbl...@brown.edu
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
I have filed the same bug on github here:
https://github.com/llvm/llvm-project/issues/181, but I am posting here for
completeness.
This happens with 10 rc2/rc3 and latest dev built from source.
This is a pretty minimal reproduction:
```
template struct Recursive {
using next = typename Recursive::type;
using type = notdefined;
};
```
Build with `clang++ -std=c++2a test.cpp`
It doesn't crash with `-std=c++17`
I made a docker container which reproduces the issue:
https://hub.docker.com/r/greenblattryan/clang-crash-recursive-template.
Backtrace: https://github.com/llvm/llvm-project/files/4333084/backtrace.txt
Here is a zip with the backtrace, preprocessed source and associated run
script.
https://github.com/llvm/llvm-project/files/4333081/bug-report.zip
--
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 44255] static Create function declared in LLJIT.h does not exist
https://bugs.llvm.org/show_bug.cgi?id=44255 Lang Hames changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||lha...@gmail.com --- Comment #1 from Lang Hames --- Thanks Raoul! I've removed the undefined decl in 049bb95c5c4185611f8240249208aef82773a79d. -- 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 21248 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-03-15 Type: Bug New issue 21248 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::DiagnosticIDs::isUnrecoverable https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21248 Detailed Report: https://oss-fuzz.com/testcase?key=5702161238589440 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffda5fd4f78 Crash State: clang::DiagnosticIDs::isUnrecoverable clang::DiagnosticIDs::ProcessDiag clang::DiagnosticsEngine::EmitCurrentDiagnostic Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202003131920:202003140256 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5702161238589440 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 21523] MCJIT debugging support.
https://bugs.llvm.org/show_bug.cgi?id=21523 Lang Hames changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Lang Hames --- Closing this as wont-fix. We already have the GDBRegistrationListener for debugging support in MCJIT (See http://llvm.org/PR1129 and http://llvm.org/PR17628). Future work will focus on OrcV2 debugging support. -- 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 45208] New: Debugging support in OrcV2 / JITLink
https://bugs.llvm.org/show_bug.cgi?id=45208 Bug ID: 45208 Summary: Debugging support in OrcV2 / JITLink Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: OrcJIT Assignee: unassignedb...@nondot.org Reporter: lha...@gmail.com CC: 1101.deb...@gmail.com, llvm-bugs@lists.llvm.org We should build an ObjectLinkingLayer plugin to enable debugging of JIT'd code. MCJIT / RuntimeDyld already has GDBRegistrationListener for this purpose. We may want to look at whether we can re-use the GDB registration protocol for this. See: http://llvm.org/PR1129, http://llvm.org/PR17628, and https://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html. If we go this route then ideally the plugin will synthesize a new object with the necessary section/segment load commands, nlist entries, and dwarf sections, but without the dead weight of all the actual code and data. -- 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
