[llvm-bugs] [Bug 48619] New: Allow std::vector::insert to compile when elements have a deleted assignment operator
https://bugs.llvm.org/show_bug.cgi?id=48619
Bug ID: 48619
Summary: Allow std::vector::insert to compile when elements
have a deleted assignment operator
Product: libc++
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: bstanimir...@gmail.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
Create a class `X` which is copy-constructible but not copy-assignable
```
struct X {
X();
X(const X&);
X& operator=(const X&) = delete; // !!
X(X&&) noexcept;
X& operator=(X&&) noexcept;
int data = 54;
};
```
Have vectors of X `a` and `b`. Try to add all elements of b at the front of a:
```
void add_to_front(std::vector& a, const std::vector& b) {
a.insert(a.begin(), b.begin(), b.end());
}
```
Live demo: https://godbolt.org/z/K1WT8n
It doesn't compile. My guess is that code which will never get invoked, still
needs to compile (or, worse yet, copy assignment does get invoked?!)
The only way to achieve the desired behavior efficiently is to use a custom
vector implementation. There is a stackoverflow question which has some *worse*
workarounds:
https://stackoverflow.com/questions/65489039/how-to-efficiently-insert-multiple-copy-constructible-but-not-copy-assignable-el
This does compile and work on msvc, so a compile-time check for the
copy-assignment code is possible.
--
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 48519] Invalid CTR loop on pwr8, but not pwr9 in the presence of half
https://bugs.llvm.org/show_bug.cgi?id=48519 Nemanja Ivanovic changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||0a19fc3088f5 Resolution|--- |FIXED --- Comment #2 from Nemanja Ivanovic --- Fixed in https://reviews.llvm.org/rG0a19fc3088f5 -- 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 47916] fatal error: error in backend: Cannot select: t184: v2i64 = PPCISD::SCALAR_TO_VECTOR_PERMUTED t107
https://bugs.llvm.org/show_bug.cgi?id=47916 Nemanja Ivanovic changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||7486de1b2ece Resolution|--- |FIXED --- Comment #6 from Nemanja Ivanovic --- Fixed in https://reviews.llvm.org/rG7486de1b2ece -- 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 48621] New: lld can't build working static PIE on Linux/x86-64
https://bugs.llvm.org/show_bug.cgi?id=48621 Bug ID: 48621 Summary: lld can't build working static PIE on Linux/x86-64 Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: hjl.to...@gmail.com CC: i...@maskray.me, llvm-bugs@lists.llvm.org, smithp...@googlemail.com When elf/ldconfig in glibc configured with --enable-static-pie is built with lld on Linux/x86-64, I got [hjl@gnu-skx-1 build-x86_64-linux]$ ./elf/ldconfig Segmentation fault (core dumped) [hjl@gnu-skx-1 build-x86_64-linux]$ One difference between lld generated ldconfig vs ld generated ldconfig is lld: Relocation section '.rela.dyn' at offset 0x318 contains 1469 entries: ld: Relocation section '.rela.dyn' at offset 0x398 contains 1434 entries: If lld can generate the same number of dynamic relocations as ld, static PIE may work with lld. -- 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 48622] New: "make check" in glibc doesn't generate test summary on Linux/x86-64
https://bugs.llvm.org/show_bug.cgi?id=48622 Bug ID: 48622 Summary: "make check" in glibc doesn't generate test summary on Linux/x86-64 Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: hjl.to...@gmail.com CC: i...@maskray.me, llvm-bugs@lists.llvm.org, smithp...@googlemail.com When lld is used to build glibc, "make check" doesn't generate test summary, like: Summary of test results: 4322 PASS 8 UNSUPPORTED 13 XFAIL 6 XPASS I can't tell how many glibc tests failed when lld is used. It is because "make check" didn't finish due to make[4]: *** [../Makerules:767: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod2.so] Error 1 make[4]: *** [../Makerules:767: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod4.so] Error 1 make[4]: *** [../Makerules:767: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-sym-lib.so] Error 1 make[4]: *** [../Makerules:767: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-absolute-zero-lib.so] Error 1 make[4]: *** [../Makerules:767: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod6.so] Error 1 make[4]: *** [../Makerules:767: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tlsmod5.so] Error 1 make[4]: *** [../Rules:226: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit16] Error 1 make[4]: *** [../Rules:226: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit14] Error 1 make[4]: *** [../Rules:226: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-audit15] Error 1 make[4]: *** [../Rules:226: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/tst-tls1] Error 1 make[4]: *** [../Rules:226: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain5] Error 1 make[4]: *** [../Rules:226: /export/users/hjl/build/gnu/tools-build/glibc-gitlab-lld/build-x86_64-linux/elf/ifuncmain1] Error 1 make[3]: *** [Makefile:479: elf/tests] Error 2 make[2]: *** [Makefile:9: check] Error 2 There are a few problems: 1. lld doesn't support 13: 0004 4 TLS GLOBAL DEFAULT COM foo 2. ld: error: cannot preempt symbol: foo_protected 3. ld: error: unknown argument '--audit=tst-auditlogmod-1.so' 4. ld: error: unknown argument '--audit=tst-auditlogmod-1.so:tst-auditlogmod-2.so' 5. ld: error: undefined symbol: absolute -- 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 48623] New: mips stdatomic.h usage includes gcc headers (and fails)
https://bugs.llvm.org/show_bug.cgi?id=48623
Bug ID: 48623
Summary: mips stdatomic.h usage includes gcc headers (and
fails)
Product: clang
Version: 11.0
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: sau...@saurik.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
There have been a number of issues filed that are similar to this over the
years, notably including #22740. This issue was considered fixed a long time
ago, and in fact I generally can't replicate it... except when compiling for
MIPS (which I'm doing using a sysroot based on Debian Stretch).
#include
static inline void CRYPTO_UP_REF(_Atomic int *val, int *ret, void *lock) {
*ret = atomic_fetch_add_explicit(val, 1, memory_order_relaxed) + 1; }
/usr/local/opt/llvm/bin/clang --sysroot
/Users/saurik/orchid/cli-shared/out-wrt/sysroot -target mips-linux-gnu -c -o
test.o test.c -v
clang -cc1 version 11.0.0 based upon LLVM 11.0.0 default target
x86_64-apple-darwin18.7.0
ignoring nonexistent directory
"/Users/saurik/orchid/cli-shared/out-wrt/sysroot/usr/local/include"
ignoring nonexistent directory
"/Users/saurik/orchid/cli-shared/out-wrt/sysroot/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/llvm/11.0.0/lib/clang/11.0.0/include
/Users/saurik/orchid/cli-shared/out-wrt/sysroot/usr/lib/gcc/mips-linux-gnu/6/include
/Users/saurik/orchid/cli-shared/out-wrt/sysroot/usr/include/mips-linux-gnu
/Users/saurik/orchid/cli-shared/out-wrt/sysroot/usr/include
End of search list.
test.c:3:12: error: address argument to atomic operation must be a pointer to
integer or pointer ('_Atomic(int) *' invalid)
*ret = atomic_fetch_add_explicit(val, 1, memory_order_relaxed) + 1; }
^~~
/Users/saurik/orchid/cli-shared/out-wrt/sysroot/usr/lib/gcc/mips-linux-gnu/6/include/stdatomic.h:195:6:
note: expanded from macro 'atomic_fetch_add_explicit'
__atomic_fetch_add ((PTR), (VAL), (MO))
^ ~
1 error generated.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 29060 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 29060 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29060#c1 ClusterFuzz testcase 4681272781832192 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012280613:202012290618 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28760 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-simplifycfg: ASSERT: isa(User) && "All external users must be PHI's."
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 28760 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-simplifycfg: ASSERT: isa(User) && "All external users must be PHI's." https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28760#c1 ClusterFuzz testcase 4879574865412096 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012280613:202012290618 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28448 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: isa(Val) && "cast() argument of incompatible type!"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 28448 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-earlycse: ASSERT: isa(Val) && "cast() argument of incompatible type!" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28448#c1 ClusterFuzz testcase 5653576860958720 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012280613:202012290618 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 28983 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm-opt-fuzzer--x86_64-instcombine
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 28983 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: Timeout in llvm-opt-fuzzer--x86_64-instcombine https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=28983#c1 ClusterFuzz testcase 6189136948101120 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012280613:202012290618 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48616] Assertion failure in MemorySSA during LTO
https://bugs.llvm.org/show_bug.cgi?id=48616 Florian Hahn changed: What|Removed |Added Fixed By Commit(s)||980bed34b96 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Florian Hahn --- Should be fixed in https://reviews.llvm.org/rGb980bed34b96 -- 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 48624] New: Miscompilation of va_start on Windows MSYS2
https://bugs.llvm.org/show_bug.cgi?id=48624
Bug ID: 48624
Summary: Miscompilation of va_start on Windows MSYS2
Product: clang
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: release blocker
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: husseyde...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Not sure if this is a Clang bug or a MSYS2 bug, so I am filing it here.
However, since the problem doesn't affect GCC which links to the same libc, I
am assuming it is something fishy with clang.
Compile this rather simple C program on MSYS2:
#include
#include
void my_printf(const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
vprintf(fmt, ap);
va_end(ap);
}
int main(void)
{
my_printf("%s\n", "Hello, world!");
}
***@ MSYS2 ~
$ clang --version
clang version 11.0.0 (https://github.com/msys2/MSYS2-packages
a5a028a0811f03c8f9697bf80c2e28111628)
Target: x86_64-pc-windows-msys
Thread model: posix
InstalledDir: /usr/bin
***@ MSYS2 ~
$ clang test.c; ./a.exe
0@
***@ MSYS2 ~
$./a.exe | hexdump -C
04 30 40 0a |.0@.|
0004
In case you are wondering, GCC correctly compiles this; my libc isn't broken.
***@ MSYS2 ~
$ gcc --version
gcc (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
***@ MSYS2 ~
$ gcc test.c; ./a.exe
Hello, world!
It doesn't matter if optimizations are on or off, it still prints 0x04 0x30
0x40.
mingw-w64 clang compiles it fine, though.
Doing some more investigation now, although I am not familiar with the calling
convention.
--
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 48625] New: Incorrect codegen for #pragma omp simd loop at -O1
https://bugs.llvm.org/show_bug.cgi?id=48625
Bug ID: 48625
Summary: Incorrect codegen for #pragma omp simd loop at -O1
Product: clang
Version: trunk
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: damatth...@smu.edu
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
The following program leads to incorrect codegen on x86-64 when compiled with
'-fopenmp-simd -O1': only every 4th (SSE) or 8th (AVX) element is summed for
large n. Changing the optimization level or enabling either FIX1 or FIX2 in the
code avoids the problem. The problem occurs in both C and C++ mode and
seemingly for any x86-64 uarch. Example of incorrect ASM:
https://godbolt.org/z/17n8bP.
```C
#ifdef __cplusplus
#define restrict __restrict
#endif
#define FIX1 0
#define FIX2 0
void sum(int n, const float* A,
#if FIX1
float* restrict value)
#else
float* value_)
#endif
{
#if !FIX1 && !FIX2
float* restrict value = (float* restrict)value_;
#endif
#if FIX2
float tmp = *value_;
float* value = &tmp;
#endif
#pragma omp simd
for (int i = 0;i < n;i++) *value += A[i];
#if FIX2
*value_ = tmp;
#endif
}
```
--
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 48626] New: clang crashes with "Call referring to the coroutine frame cannot be marked as musttail"
https://bugs.llvm.org/show_bug.cgi?id=48626
Bug ID: 48626
Summary: clang crashes with "Call referring to the coroutine
frame cannot be marked as musttail"
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Transformation Utilities
Assignee: unassignedb...@nondot.org
Reporter: cyg...@michiru.ru
CC: gornisha...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 24320
--> https://bugs.llvm.org/attachment.cgi?id=24320&action=edit
Original non-minified reproducer
(There's no component for bugs in lib/Transforms/Coroutines and I see no system
in how other bugs with a "coroutine" in title are reported that are not clang
frontend-specific, which could be reported as product:clang/component:c++2a;
please adjust as needed.)
llvm/lib/Transforms/Coroutines/CoroElide.cpp:87 in removeTailCallAttribute
called from Lowerer::elideHeapAllocations says:
// FIXME: If we ever hit this check. Evaluate whether it is more
// appropriate to retain musttail and allow the code to compile.
Well, this happened for me. Here's the result from reducing original
preprocessed code with cvise and manually editing it to make some sense, some
functions happen to be undefined here as that matters for the bug to manifest,
this wasn't the case in the original code that I have left attached in case it
would help.
$ cat bug.cpp
#include
namespace stdcoro = std::experimental;
template
struct coroutine
{
struct promise_type
{
struct final_awaitable : stdcoro::suspend_always
{
stdcoro::coroutine_handle<>
await_suspend(stdcoro::coroutine_handle<>) noexcept;
};
Result result_;
coroutine get_return_object() noexcept
{
return *this;
}
stdcoro::suspend_always initial_suspend() noexcept
{
return {};
}
auto final_suspend() noexcept
{
if constexpr(SaveAwaiter)
return final_awaitable{};
else
return stdcoro::suspend_always{};
}
void unhandled_exception()
{
__builtin_unreachable();
}
void return_value(int result)
{
result_ = result;
}
Result result()
{
return result_;
}
};
using handle_t = stdcoro::coroutine_handle;
using result_type = Result;
handle_t handle_;
~coroutine()
{
handle_.destroy();
}
auto operator()() noexcept
{
struct coroutine_result
{
coroutine *coro_;
coroutine_result(coroutine *coro)
: coro_{coro}
{
coro_->handle_();
}
operator result_type()
{
return coro_->handle_.promise().result();
}
};
return coroutine_result{this};
}
coroutine(promise_type& promise)
:
handle_{stdcoro::coroutine_handle::from_promise(promise)}
{}
};
template void report(T);
extern template void report(int);
template
void expect(T assertion)
{
if(!assertion)
report(assertion);
}
int main()
{
[]() -> coroutine {
expect([]() -> coroutine { co_return 1; }()());
co_return 0;
}();
}
$ lldb -- clang++ -O2 -std=c++20 -c bug.cpp
(lldb) target create "clang++"
Current executable set to 'clang++' (x86_64).
(lldb) settings set -- target.run-args "-O2" "-std=c++20" "-c" "bug.cpp"
(lldb) b LLVMErrorHandler
Breakpoint 1: 2 locations.
(lldb) r
Process 807971 launched: '/usr/lib/llvm/12/bin/clang++' (x86_64)
Process 807971 stopped
* thread #1, name = 'clang++', stop reason = breakpoint 1.1
frame #0: 0x0022b604
clang++`LLVMErrorHandler(UserData=0x002925e0, Message="Call referring
to the coroutine frame cannot be marked as musttail", GenCrashDiag=true) at
cc1_main.cpp:64:9
61bool GenCrashDiag) {
62 DiagnosticsEngine &Diags =
*static_cast(UserData);
63
-> 64 Diags.Report(diag::err_fe_error_backend) << Message;
65
66 // Run the interrupt handlers to make sure any special cleanups get
done, in
67 // particular that we remove files registered with
RemoveFileOnSignal.
(lldb) bt
* thread #1, name = 'clang++', stop reason = breakpoint 1.1
* frame #0: 0x0022b604
clang++`LLVMErrorHandler(UserData=0x002925e0, Message="Call referring
to the coroutine frame cannot be marked as musttail", GenCrashDiag=true) at
cc1_main.cpp:64:9
frame #1: 0x71a46e60
libLLVM-12libcxx.so`llvm::report_fatal_error(Reason=0x7fff97d0,
GenCrashDiag=true) at ErrorHandling.cpp:108:5
frame #2: 0x71a46d51
libLLVM-12libcxx.so`llvm::report_fatal_error(Reason=,
GenCrashDiag=) at Err
[llvm-bugs] Issue 29087 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::IdentifierResolver::begin
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 Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-12-30 Type: Bug New issue 29087 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::IdentifierResolver::begin https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29087 Detailed Report: https://oss-fuzz.com/testcase?key=6252189962076160 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdc22c8fe0 Crash State: clang::IdentifierResolver::begin clang::Sema::CppLookupName clang::Sema::LookupName Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202012280613:202012290618 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6252189962076160 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 48627] New: crash in tail call elimination of C++2a coroutines on MIPS
https://bugs.llvm.org/show_bug.cgi?id=48627
Bug ID: 48627
Summary: crash in tail call elimination of C++2a coroutines on
MIPS
Product: clang
Version: 11.0
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: sau...@saurik.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
Created attachment 24321
--> https://bugs.llvm.org/attachment.cgi?id=24321&action=edit
the flattened code generated in the crash report
Here is a somewhat-whittled test case of a compiler crash trying to use
coroutines on MIPS.
/usr/local/opt/llvm/bin/clang++ --sysroot debian-stretch-ish -target
mips-linux-gnu -c -o test.o -std=c++2a -Os -fcoroutines-ts -nostdinc++ -isystem
env/libcxx/include -isystem env/libcxxabi/include test.cpp
libcxx: 2076f539f410805ef88692b9c0ce0a0b882a7680
libcxxabi: a88633b46c401e6be38b93cf08660f137f86664d
$ /usr/local/opt/llvm/bin/clang++ --version
clang version 11.0.0
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
#include
struct Task {
struct promise_type {
std::experimental::coroutine_handle<> code_;
auto initial_suspend() noexcept {
return std::experimental::suspend_always(); }
auto final_suspend() noexcept {
return std::experimental::suspend_always(); }
auto get_return_object() noexcept {
return
Task(std::experimental::coroutine_handle::from_promise(*this));
}
void unhandled_exception() noexcept {}
void return_void() noexcept {}
void operator *() {}
};
std::experimental::coroutine_handle code_;
Task(std::experimental::coroutine_handle code) noexcept :
code_(std::move(code)) {}
bool await_ready() noexcept {
return !code_ || code_.done(); }
template
auto await_suspend(std::experimental::coroutine_handle code)
noexcept {
code_.promise().code_ = std::move(code);
return code_;
}
auto await_resume() const {
return *this->code_.promise();
}
};
Task f();
Task g() { co_await f(); }
fatal error: error in backend: failed to perform tail call elimination on a
call site marked musttail
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/local/opt/llvm/bin/clang++ --sysroot
/Users/saurik/orchid/cli-shared/out-wrt/sysroot -target mips-linux-gnu -c -o
test.o -std=c++2a -Os -fcoroutines-ts -nostdinc++ -isystem env/libcxx/include
-isystem env/libcxxabi/include test.cpp
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'test.cpp'.
4. Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function
'@_Z1gv.resume'
0 libLLVM.dylib 0x0001041da6c4
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1 libLLVM.dylib 0x0001041da141 llvm::sys::CleanupOnSignal(unsigned
long) + 184
2 libLLVM.dylib 0x000104146b61 (anonymous
namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) + 97
3 libLLVM.dylib 0x000104146afe
llvm::CrashRecoveryContext::HandleExit(int) + 14
4 libLLVM.dylib 0x0001041d7927 llvm::sys::Process::Exit(int) + 35
5 clang++0x00010195a73d LLVMErrorHandler(void*,
std::__1::basic_string,
std::__1::allocator > const&, bool) + 180
6 libLLVM.dylib 0x00010414f369 llvm::report_fatal_error(llvm::Twine
const&, bool) + 254
7 libLLVM.dylib 0x00010414f26b llvm::report_fatal_error(llvm::Twine
const&, bool) + 0
8 libLLVM.dylib 0x00010582cad6
llvm::MipsTargetLowering::LowerCall(llvm::TargetLowering::CallLoweringInfo&,
llvm::SmallVectorImpl&) const + 5702
9 libLLVM.dylib 0x00010463fce0
llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&)
const + 3798
10 libLLVM.dylib 0x0001046558de
llvm::SelectionDAGBuilder::lowerInvokable(llvm::TargetLowering::CallLoweringInfo&,
llvm::BasicBlock const*) + 386
11 libLLVM.dylib 0x0001046452c7
llvm::SelectionDAGBuilder::LowerCallTo(llvm::CallBase const&, llvm::SDValue,
bool, llvm::BasicBlock const*) + 1483
12 libLLVM.dylib 0x0001046374e4
llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 1170
13 libLLVM.dylib 0x00010462ff87
llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 113
14 libLLVM.dylib 0x0001046964b5
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>,
llvm::ilist_iterator, false, true>, bool&) + 155
15 libLLVM.dylib 0x0001046961d4
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3686
16 libLLVM.
