[llvm-bugs] [Bug 48017] New: [AArch64] Under -O0, atomicrmw contains an extra store in the ldaxr/stlxr loop
https://bugs.llvm.org/show_bug.cgi?id=48017
Bug ID: 48017
Summary: [AArch64] Under -O0, atomicrmw contains an extra store
in the ldaxr/stlxr loop
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: AArch64
Assignee: unassignedb...@nondot.org
Reporter: rofir...@gmail.com
CC: arnaud.degrandmai...@arm.com,
llvm-bugs@lists.llvm.org, smithp...@googlemail.com,
ties.st...@arm.com
Created attachment 24112
--> https://bugs.llvm.org/attachment.cgi?id=24112&action=edit
LLVM IR snippet at -O0 (slightly simplified)
The following C++ snippet compiled under -O0
#include
std::atomic _value(0);
void foo() { _value += 1; }
generates the attached IR (slightly simplified). That IR is emitted under -O0
with the usual ldaxr/stlxr loop.
$ llc -O0 -mtriple aarch64 -o - myatomic.ll
...
.LBB0_1:// %atomicrmw.start
// =>This Inner Loop Header: Depth=1
ldr x10, [sp, #16] // 8-byte Folded Reload
ldr w9, [sp, #24] // 4-byte Folded Reload
ldaxr w8, [x10]
// kill: def $x8 killed $w8
// kill: def $w8 killed $w8 killed $x8
str w8, [sp, #12] // 4-byte Folded Spill (!!!)
add w9, w8, w9
stlxr w8, w9, [x10]
cbnzw8, .LBB0_1
...
When using this code in a ThunderX machine, this loop hangs.
That extra `str` instruction (which looks like a side-effect of the register
allocator) seems to make the exclusive access be lost and the code loops
forever. This might be fallout from the recent rewrite of RegAllocFast.
Now, this is odd because:
- That store accesses the stack while x10 is a global address, so they are far
enough that that str shouldn't make the exclusive access be lost.
- This problem doesn't happen in all aarch64 implementations: Raspberry Pi 4
or A64FX are unaffected. We have only been able to reproduce this reliably on a
ThunderX machine.
So to be honest I'm not sure if:
- This is a bug of that ThunderX.
- This is a bug in LLVM.
For the latter case, the Armv8-A spec (Issue E.a of the document) says in
§B2.9.5 that:
"LoadExcl / StoreExcl loops are guaranteed to make forward progress only if,
for any LoadExcl / StoreExcl loop within a single thread of execution, the
software meets all of the following conditions:
1. Between the Load-Exclusive and the Store-Exclusive, there are no explicit
memory accesses, preloads, direct or indirect System register writes, address
translation instructions, cache or TLB maintenance instructions, exception
generating instructions, exception returns, or indirect branches"
This could suggest that that store better not be inside that loop if we want to
guarantee progress in all aarch64 implementations. However I'm no expert in
this area and perhaps that loop is OK and we're observing a problem in our
particular aarch64 implementation.
clang/llvm 11.0 is unaffected.
--
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 48018] New: Assertion failed: (ESI.Type != EST_Uninstantiated), function SubstExceptionSpec
https://bugs.llvm.org/show_bug.cgi?id=48018 Bug ID: 48018 Summary: Assertion failed: (ESI.Type != EST_Uninstantiated), function SubstExceptionSpec Product: clang Version: trunk Hardware: Macintosh OS: MacOS X Status: NEW Severity: release blocker Priority: P Component: C++2a Assignee: unassignedclangb...@nondot.org Reporter: dodoentertainm...@gmail.com CC: blitzrak...@gmail.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 24115 --> https://bugs.llvm.org/attachment.cgi?id=24115&action=edit preprocessed source and crash reproducer script The original report of this crash can be found on [Emscripten github](https://github.com/emscripten-core/emscripten/issues/12639): I've stumbled upon this crash with Emscripten 2.0.8 when building our internal code. Fortunately, I've been able to reproduce it completely using open source code. I've created a [repository](https://github.com/DoDoENT/functionoid-emscripten-crash) containing the crash reproducer. So, to reproduce the crash, please do as follows: ```bash git clone https://github.com/DoDoENT/functionoid-emscripten-crash.git pushd functionoid-emscripten-crash git submodule update --init popd mkdir build cd build emcmake cmake -GNinja -DCMAKE_BUILD_TYPE=Release ../functionoid-emscripten-crash ninja ``` I tested with Emscripten 2.0.8 on MacOS Catalina 10.15.7 The complete trace is ``` Assertion failed: (ESI.Type != EST_Uninstantiated), function SubstExceptionSpec, file /opt/s/w/ir/cache/builder/emscripten-releases/llvm-project/clang/lib/Sema/SemaTemplateInstantiate.cpp, line 2194. 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: /Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/bin/clang++ -target wasm32-unknown-emscripten -D__EMSCRIPTEN_major__=2 -D__EMSCRIPTEN_minor__=0 -D__EMSCRIPTEN_tiny__=8 -D_LIBCPP_ABI_VERSION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -nostdsysteminc -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/include/libcxx -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/lib/libcxxabi/include -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/include/compat -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/include -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/include/libc -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/lib/libc/musl/arch/emscripten -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/local/include -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/include/SSE -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/include/neon -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/lib/compiler-rt/include -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/upstream/emscripten/system/lib/libunwind/include -Xclang -isystem/Users/dodo/.conan/data/emsdk_installer/2.0.8/microblink/stable/package/743cf0321be3152777da4d05247a66d1552e70a2/.emscripten_cache/wasm-lto/include -DEMSCRIPTEN -fignore-exceptions -I/Users/dodo/Work/Microblink/Builds/tmp/functionoid-emscripten-crash/functionoid/include -I/Users/dodo/Work/Microblink/Builds/tmp/functionoid-emscripten-crash/config_ex/include -I/Users/dodo/Work/Microblink/Builds/tmp/functionoid-emscripten-crash/boost/include -DNDEBUG -O2 -fstrict-aliasing -fstrict-enums -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -flto -fwhole-program-vtables -std=gnu++2a -fno-threadsafe-statics -fno-rtti -fomit-frame-pointer -ffunction-sections -fmerge-all-constants -fno-stack-protector -Wall -Wextra -Wstrict-aliasing -MD -MT CMakeFi
[llvm-bugs] [Bug 48019] New: lld: unexpected segmentation fault linking MachO
https://bugs.llvm.org/show_bug.cgi?id=48019 Bug ID: 48019 Summary: lld: unexpected segmentation fault linking MachO Product: lld Version: unspecified Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: MachO Assignee: unassignedb...@nondot.org Reporter: kub...@jakubkonka.com CC: llvm-bugs@lists.llvm.org I've encountered this bug in the latest LLVM release 11.0.0. The link to upstream issue: https://github.com/ziglang/zig/issues/6812. I haven't had the time to create the minimal reduction yet, but will do my best to come up with something ASAP. I'll also test it against the LLVM upstream, and see if the issue has already been fixed. Having said that, if anyone knows of any fix, I'd really appreciate any links to some diffs. Finally, I'll be happy to work on a fix for this if it's not fixed yet. Stack dump: 0. Program arguments: /usr/local/opt/llvm/bin/ld64.lld -error-limit 0 -demangle -dynamic -arch x86_64 -macosx_version_min 10.15.7 -sdk_version 10.15.7 -pie -o /Users/kubkon/dev/zig-upaya/zig-cache/o/07bf65c94971f0f1cc20b8d266576fe7/tilemap /Users/kubkon/dev/zig-upaya/zig-cache/o/deacba273d1175327b5f594b7bd69197/compile_sokol.o /Users/kubkon/dev/zig-upaya/zig-cache/o/6a165678cebdac1b7a7c8256eec6f594/stb_impl.o /Users/kubkon/dev/zig-upaya/zig-cache/o/9ea479ff48bb3e3a3e5357065c60a829/imgui.o /Users/kubkon/dev/zig-upaya/zig-cache/o/a56785dce35f94882513fac0f8c70df0/imgui_demo.o /Users/kubkon/dev/zig-upaya/zig-cache/o/f83b504afe46e0e855f3e06ff20e80b4/imgui_draw.o /Users/kubkon/dev/zig-upaya/zig-cache/o/103aa42f786819f86280c8bf1109a22a/imgui_widgets.o /Users/kubkon/dev/zig-upaya/zig-cache/o/a9b9caa6993701160a1391f88a76717b/cimgui.o /Users/kubkon/dev/zig-upaya/zig-cache/o/b2d5f0792d3cf747952365ce53d8b355/temporary_hacks.o /Users/kubkon/dev/zig-upaya/zig-cache/o/93f57e0f29fba267cae0ad1d4de7ff7d/tinyfiledialogs.o /Users/kubkon/dev/zig-upaya/zig-cache/o/07bf65c94971f0f1cc20b8d266576fe7/tilemap.o /Users/kubkon/.cache/zig/o/a3bc26d320a45a7acb35de34821443e0/libcompiler_rt.a /Users/kubkon/.cache/zig/o/a5d09af89feb0aefd87afe02a373659a/libc++abi.a /Users/kubkon/.cache/zig/o/ef84161c4c2bc05766fd8b1c5f99603c/libc++.a -lSystem -F /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks -F /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks -framework Foundation -framework QuartzCore -framework Metal -framework MetalKit -framework OpenGL -framework Cocoa -framework Quartz -framework Audiotoolbox -framework CoreAudio 0 libLLVM.dylib0x0001104a6535 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37 1 libLLVM.dylib0x0001104a69dc SignalHandler(int) + 200 2 libsystem_platform.dylib 0x7fff6780a5fd _sigtramp + 29 3 libsystem_platform.dylib 0x7ffedfdbd9ce _sigtramp + 18446744071433827310 4 ld64.lld 0x0001100a015d lld::mach_o::MachODylibFile::exports(llvm::StringRef, llvm::StringRef) const + 53 5 ld64.lld 0x0001100a01db lld::mach_o::MachODylibFile::exports(llvm::StringRef, llvm::StringRef) const + 179 6 ld64.lld 0x0001100a01db lld::mach_o::MachODylibFile::exports(llvm::StringRef, llvm::StringRef) const + 179 7 ld64.lld 0x0001100b lld::mach_o::MachODylibFile::exports(llvm::StringRef) const + 28 8 ld64.lld 0x0001100d9e02 std::__1::__function::__func, llvm::Expected (llvm::StringRef)>::operator()(llvm::StringRef&&) + 52 9 ld64.lld 0x0001100d824d lld::Resolver::forEachUndefines(lld::File&, std::__1::function (llvm::StringRef)>) + 309 10 ld64.lld 0x0001100d8444 lld::Resolver::handleSharedLibrary(lld::File&) + 154 11 ld64.lld 0x0001100d8b78 lld::Resolver::resolveUndefines() + 882 12 ld64.lld 0x0001100d9ae8 lld::Resolver::resolve() + 14 13 ld64.lld 0x00010fec7bfd lld::mach_o::link(llvm::ArrayRef, bool, llvm::raw_ostream&, llvm::raw_ostream&) + 389 14 ld64.lld 0x00010fe42ba6 main + 875 15 libdyld.dylib0x7fff67611cc9 start + 1 16 libdyld.dylib0x0032 start + 18446603338781746026 [1]14588 segmentation fault /usr/local/opt/llvm/bin/ld64.lld -error-limit 0 -demangle -dynamic -arch -- 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 47372] lambda static invoker does not inherit calling convention attribute from operator()
https://bugs.llvm.org/show_bug.cgi?id=47372 Erich Keane changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||ec809e4cfe0be08b1bab7ba7e6f ||f905b9430571a --- Comment #3 from Erich Keane --- Fixed in https://reviews.llvm.org/D89559 and ec809e4cfe0be08b1bab7ba7e6ff905b9430571a Work on MSVC 'emit all the conversions' to come as a future patch. -- 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 48020] New: Defining constrained member function out of line is rejected
https://bugs.llvm.org/show_bug.cgi?id=48020
Bug ID: 48020
Summary: Defining constrained member function out of line is
rejected
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: barry.rev...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
>From StackOverflow (https://stackoverflow.com/q/64601583/2069064):
template concept C = true;
template
struct Foo { };
template
requires C
struct Foo {
static void bar();
};
template
requires C
void Foo::bar() { }
int main() {
Foo::bar();
}
clang 11 rejects this program with:
:13:10: error: requires clause differs in template redeclaration
requires C
^
:3:1: note: previous template declaration is here
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
[llvm-bugs] Issue 26716 in oss-fuzz: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t"
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #1 on issue 26716 by ClusterFuzz-External: llvm:llvm-opt-fuzzer--x86_64-instcombine: ASSERT: getActiveBits() <= 64 && "Too many bits for uint64_t" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26716#c1 ClusterFuzz testcase 5194806403530752 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202010290614:202010300616 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 48021] New: lldb - nicer command to search for Bytes
https://bugs.llvm.org/show_bug.cgi?id=48021
Bug ID: 48021
Summary: lldb - nicer command to search for Bytes
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: rustymagnet3...@gmail.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
lldb-1200.0.32.1
/*** sample code **/
// Baboon
// 0x42, 0x61, 0x62, 0x6f, 0x6f, 0x6e
const int animalByteArray[7] = { 66, 97, 98, 111, 111, 110 };
void foo_func (const void *ptr) {
printf ("\n[*]Pointer: %p.\n", ptr);/* breakpoint here */
}
int main (void) {
const int *ptr = animalByteArray;
puts ("[*]Can you change the animal?\n");
for (; *ptr != '\0'; ++ptr)
printf ("%c", *ptr);
foo_func (ptr);
return 0;
}
/***/
// Once breakpoint fires, get start and end positions for Memory Search
(lldb) section
[0x01-0x014000] 0x004000 objc_play`__TEXT
// Memory find for "B", max matches of three, from start to end address
(lldb) mem find -s "B" -c 3 -- 0x01 0x014000
WORKS
(lldb) mem find -s "B " -c 3 -- 0x01 0x014000
WORKS
But I try something more intuative:
(lldb) mem find -s "Ba" -c 3 -- 0x01 0x014000
FAILS
(lldb) mem find -s "Baboon" -c 3 -- 0x01 0x014000
FAILS
(lldb) mem find -e "\42\61" -c 10 -- 0x01 0x014000
FAILS
(lldb) mem find -e "\x42\x61" -c 10 -- 0x01 0x014000
FAILS
If I try the same with radare2 tools:
▶ rabin2 -qz objc_play
0x13f60 28 6 Baboon
Ultimately, I am trying to figure out how to write the byte buffer I pass the
lldb-python SBProcess.ReadMemory API.
--
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 48022] New: Regression: Assertion failure at kmp_dispatch
https://bugs.llvm.org/show_bug.cgi?id=48022
Bug ID: 48022
Summary: Regression: Assertion failure at kmp_dispatch
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: jan-grimo.so...@phys.chem.ethz.ch
CC: llvm-bugs@lists.llvm.org
The following code non-deterministically trips a runtime assert on ubuntu 20.04
with the official llvm-apt clang 11 package:
int main() {
#pragma omp parallel for schedule(dynamic)
for (int c = 0; c < 15; ++c)
#pragma omp parallel
;
}
The runtime assert is:
Assertion failure at kmp_dispatch.cpp(1332): victim.
OMP: Error #13: Assertion failure at kmp_dispatch.cpp(1332).
OMP: Hint Please submit a bug [...]
Relevant flags used for building (from CMake-generated Makefile) were:
CXX_FLAGS = -O3 -DNDEBUG -march=native -fopenmp=libomp
Link command:
/usr/bin/clang++-11 -O3 -DNDEBUG CMakeFiles/crash.dir/main.cpp.o -o crash
/usr/lib/llvm-11/lib/libomp.so /usr/lib/x86_64-linux-gnu/libpthread.so
Execution: no omp env variables set
The code is the result of several iterations of test case minimization and
by-hand refactoring. The interestingness script for the test case minimization
allows up to 100 executions of the program for tripping the assert, so you may
need to repeat execution rapidly for this to trip.
Minimum number of threads I was able to reproduce this with is four. I was
unable to reproduce this with clang 10.
--
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 47861] Lifetime of temporaries inconsistently extending when optiimzations are enabled
https://bugs.llvm.org/show_bug.cgi?id=47861 Chris Savoie changed: What|Removed |Added Resolution|INVALID |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 48023] New: Should LLD synthesize STT_FILE symbols when copying local symbols?
https://bugs.llvm.org/show_bug.cgi?id=48023 Bug ID: 48023 Summary: Should LLD synthesize STT_FILE symbols when copying local symbols? Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: i...@maskray.me CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com The ELF spec says > STT_FILE - Conventionally, the symbol's name gives the name of the source > file associated with the object file. A file symbol has STB_LOCAL binding, > its section index is SHN_ABS, and it precedes the other STB_LOCAL symbols for > the file, if it is present. If an object file has STB_LOCAL non-STT_SECTION symbols like (ARM $a). LLD copies them to the output which may be attributed to the previous file (with STT_FILE). If we synthesize a STB_LOCAL STT_FILE SHN_ABS symbol, we can resolve this problem. However, this behavior can be inconvenient in some cases. The compiler passes the absolute paths of files like crti.o crtn.o to ld.bfd, so ld.bfd will synthesize STT_FILE symbols with absolute paths. If the user wants to pursue "Local determinism: Like incremental basic determinism, but builds are also independent of the name of the build directory" (https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html), the absolute path can actually get in the way. -- 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 24758 in oss-fuzz: llvm:clangd-fuzzer: Stack-overflow in llvm::json::Parser::parseValue
Updates: Labels: Deadline-Approaching Comment #1 on issue 24758 by sheriffbot: llvm:clangd-fuzzer: Stack-overflow in llvm::json::Parser::parseValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24758#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 24762 in oss-fuzz: llvm:clang-fuzzer: ASSERT: D.isPastIdentifier() && "Haven't past the location of the identifier yet?"
Updates: Labels: Deadline-Approaching Comment #1 on issue 24762 by sheriffbot: llvm:clang-fuzzer: ASSERT: D.isPastIdentifier() && "Haven't past the location of the identifier yet?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24762#c1 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- 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 48024] New: llvm-mca crashes with LDMXCSR and STMXCSR instructions in combination for some architectures.
https://bugs.llvm.org/show_bug.cgi?id=48024 Bug ID: 48024 Summary: llvm-mca crashes with LDMXCSR and STMXCSR instructions in combination for some architectures. Product: new-bugs Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tohe_...@gmx.de CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org The llvm-mca tool crashes with the following assembly for some architectures: stmxcsr dword ptr [rsp - 4] mov eax, -24577 and eax, dword ptr [rsp - 4] mov dword ptr [rsp - 8], eax ldmxcsr dword ptr [rsp - 8] ret (Here is a Godbolt Compiler Explorer Link for it: https://gcc.godbolt.org/z/adh57E) The problem is present for at least Bulldozer, Piledriver, Haswell, Broadwell, Silvermont and Goldmont architecture. llvm-mca does not crash if only either the LDMXCSR or the STMXCSR instruction is present but not both simultanously including the bitwise manipulation. The problem does not occur either if one of Zen, Zen 2, Penryn, Westmere, Nehalem, Sandy Bridge, Ivy Bridge, Skylake or Cannonlake is specified as the scheduling model. The error message is as follows: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: /llvm-mca --mcpu=bdver2 #0 0x559cd340b0cc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/llvm-mca+0x6810cc) #1 0x559cd3408fa4 llvm::sys::RunSignalHandlers() (/llvm-mca+0x67efa4) #2 0x559cd3409113 SignalHandler(int) (/llvm-mca+0x67f113) #3 0x7fcf53be23c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0) #4 0x559cd3317600 llvm::mca::LSUnit::dispatch(llvm::mca::InstRef const&) (/llvm-mca+0x58d600) #5 0x559cd3320365 llvm::mca::Scheduler::dispatch(llvm::mca::InstRef&) (/llvm-mca+0x596365) #6 0x559cd332cc6e llvm::mca::ExecuteStage::execute(llvm::mca::InstRef&) (/llvm-mca+0x5a2c6e) #7 0x559cd332a71a llvm::mca::DispatchStage::dispatch(llvm::mca::InstRef) (/llvm-mca+0x5a071a) #8 0x559cd332a769 llvm::mca::DispatchStage::execute(llvm::mca::InstRef&) (.localalias.70) (/llvm-mca+0x5a0769) #9 0x559cd332b976 llvm::mca::EntryStage::execute(llvm::mca::InstRef&) (.localalias.72) (/llvm-mca+0x5a1976) #10 0x559cd332988c llvm::mca::Pipeline::runCycle() (/llvm-mca+0x59f88c) #11 0x559cd3329a26 llvm::mca::Pipeline::run() (/llvm-mca+0x59fa26) #12 0x559cd3047871 runPipeline(llvm::mca::Pipeline&) (/llvm-mca+0x2bd871) #13 0x559cd303aa72 main (/llvm-mca+0x2b0a72) #14 0x7fcf5369b0b3 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b3) #15 0x559cd304413a _start (/llvm-mca+0x2ba13a) -- 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 48026] New: Rejects valid direct initialization from prvalue (private destructor)
https://bugs.llvm.org/show_bug.cgi?id=48026
Bug ID: 48026
Summary: Rejects valid direct initialization from prvalue
(private destructor)
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: leni...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
clang version 10.0.1 (https://github.com/llvm/llvm-project.git
ef32c611aa214dea855364efd7ba451ec5ec3f74)
options: -std=c++17 -O2 -pedantic-errors
clang++ rejects the following well-formed program:
struct A {
private:
~A();
public:
static A f();
};
A* foo() {
return new A(A::f());
}
https://godbolt.org/z/hffYq7
On the return line no destructor is invoked or potentially invoked.
--
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 48027] New: -Winvalid-constexpr fails to warn when calling non-constexpr method on field
https://bugs.llvm.org/show_bug.cgi?id=48027
Bug ID: 48027
Summary: -Winvalid-constexpr fails to warn when calling
non-constexpr method on field
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: com...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
The below should warn that y() can never be constant evaluated, but fails to as
of current trunk. Either of the following changes will restore the warning:
- Changing `void x()` to `static void x()`
- Changing `constexpr void y()` to `constexpr void y(X x)`
struct X {
void x();
};
struct Y {
X x;
constexpr void y() { x.x(); }
};
--
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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42513, which changed state. Bug 42513 Summary: Friend function declarations hidden in qualifed name lookup (regression introduced by commit r350505) https://bugs.llvm.org/show_bug.cgi?id=42513 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 42513] Friend function declarations hidden in qualifed name lookup (regression introduced by commit r350505)
https://bugs.llvm.org/show_bug.cgi?id=42513
Andy Gibbs changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #3 from Andy Gibbs ---
Hi again, I've been reviewing the fix for this bug and it seems it is still
incomplete, unfortunately. Therefore, with your permission, I have re-opened
the bug.
The following is another code sample that was broken by commit r350505 but in
this case not fixed by commit r369384. Again, the code sample compiled
correctly in clang 7.0 and compiles correctly in gcc.
/***/
template
struct Instance
{
constexpr Instance(decltype(nullptr)) : x(nullptr) { }
explicit constexpr operator bool() const
{ return (x != nullptr); }
constexpr const X* operator->() const
{ return x; }
private:
constexpr Instance(const X* x) : x(x) { }
friend constexpr auto GetInstanceImpl(X*)
{ return +[](){ return Instance(&instance); }; }
const X* x;
static constexpr X instance { };
};
struct GetInstanceHelper
{
template
static constexpr auto GetInstance(Y*)
{ return Ret; }
template
static constexpr auto GetInstance(...)
{ return nullptr; }
};
template
static constexpr Instance GetInstance()
{
constexpr auto i = GetInstanceHelper::GetInstance(0);
if constexpr (i != nullptr)
return i();
else
return nullptr;
}
struct X1
{
constexpr X1() { }
friend constexpr auto GetInstanceImpl(X1*);
constexpr int getValue() const
{ return 7; }
};
template struct Instance;
constexpr int test()
{
int value = 0;
if (auto i = GetInstance())
value += i->getValue();
return value;
}
static_assert(test() == 7, "oops");
/***/
--
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 23514] Out-of-sequence initialiser causes clang to crash
https://bugs.llvm.org/show_bug.cgi?id=23514 Andy Gibbs changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andy Gibbs --- Just tidying up this old bug report: this is fixed in latest clang versions; thanks! -- 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 48028] New: clang fails to start with "realloc(): invalid old size" on ppc64el
https://bugs.llvm.org/show_bug.cgi?id=48028 Bug ID: 48028 Summary: clang fails to start with "realloc(): invalid old size" on ppc64el Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: Backend: PowerPC Assignee: unassignedb...@nondot.org Reporter: sylves...@debian.org CC: llvm-bugs@lists.llvm.org, nemanja.i@gmail.com Reported here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972333 It seems it was caused by a new version of binutils (2.35.1-2 probably): https://tracker.debian.org/news/1181645/accepted-binutils-2351-2-source-into-unstable/ Maybe these patches? https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4d8ee860737005517be588f4771c358593fa421c https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=e6f04d55f681149a69102a73937d0987719c3f16;hp=55b8e31a7a109bbd4efd7a59408c3c59dcf62ee0 % /home/sylvestre/llvm-toolchain-11-11.0.0/build-llvm/tools/clang/stage2-bins/bin/clang++ realloc(): invalid old size -- 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 33073] PowerPC: Invalid code generation causing SEGV
https://bugs.llvm.org/show_bug.cgi?id=33073 Andy Gibbs changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andy Gibbs --- I'm closing this very old bug. It turned out in the end that the problem was not caused by the compiler, but by a stack-overrun error in the sqlite library. It has (long) since been fixed and the latest sqlite libraries do not exhibit this issue. The change in code generation between clang 3.8 and 4.0 simply brought this to light. -- 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 48029] New: Rust function of sufficient length prevents breakpoints from working
https://bugs.llvm.org/show_bug.cgi?id=48029
Bug ID: 48029
Summary: Rust function of sufficient length prevents
breakpoints from working
Product: lldb
Version: 11.0
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: d...@fritch.mn
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Following up on an issue originally reported to the VsCode plug-in CodeLLDB:
https://github.com/vadimcn/vscode-lldb/issues/369
Both the author and I reached the conclusion this comes back to LLDB.
Discovered upon porting an existing (long, ~5k LOC) C function into Rust. With
this code in place, breakpoints are not resolved:
```
break list
Current breakpoints:
1: file = 'src/main.rs', line = 4, exact_match = 0, locations = 0 (pending)
2: file = 'main.rs', line = 5, exact_match = 0, locations = 0 (pending)
3: file = 'src/tests.rs', line = 13, exact_match = 0, locations = 0 (pending)
4: Exception breakpoint (catch: on throw: on) using: names =
{'__cxa_begin_catch', '__cxa_throw', '__cxa_rethrow'}, modules(2) =
libc++abi.dylib, libSystem.B.dylib
5: name = 'rust_panic', locations = 1, resolved = 1, hit count = 0
5.1: where = spice21`rust_panic + 20 at panicking.rs:626:9, address =
0x0001000acb04, resolved, hit count = 0
```
This is despite debug info being present:
```
dsymutil -s target/debug/spice21 | grep N_OSO
[ 920] 000269e1 66 (N_OSO) 03 0001
'target/debug/deps/spice21.1qcu4jwi3fjtxyk9.rcgu.o'
[ 933] 00026a80 66 (N_OSO) 03 0001
'target/debug/deps/spice21.2ql4572xdsy6ks1i.rcgu.o'
[ 946] 00026c09 66 (N_OSO) 03 0001
'target/debug/deps/spice21.2xq4mz9sgc2ysmfp.rcgu.o'
[ 955] 00026d3a 66 (N_OSO) 03 0001
'target/debug/deps/spice21.36d1auo9zjn0ja0b.rcgu.o'
[ 978] 00026f7c 66 (N_OSO) 03 0001
'target/debug/deps/spice21.3nan5uievwffbtlg.rcgu.o'
[ 991] 000270b8 66 (N_OSO) 03 0001
'target/debug/deps/spice21.4tcozfs9ntfwgd8y.rcgu.o'
[ 1001] 00027208 66 (N_OSO) 03 0001
'target/debug/deps/libspice21-1f365d6b281ad2bf.rlib(spice21-1f365d6b281ad2bf.11mevay8dm2eejnt.rcgu.o)'
[ 1029] 000274f8 66 (N_OSO) 03 0001
'target/debug/deps/libspice21-1f365d6b281ad2bf.rlib(spice21-1f365d6b281ad2bf.13zfg5ipncreabid.rcgu.o)'
[ 1039] 000276bf 66 (N_OSO) 03 0001
'target/debug/deps/libspice21-1f365d6b281ad2bf.rlib(spice21-1f365d6b281ad2bf.1442y1ntqkhpbe43.rcgu.o)'
[ 1048] 0002780c 66 (N_OSO) 03 0001
'target/debug/deps/libspice21-1f365d6b281ad2bf.rlib(spice21-1f365d6b281ad2bf.14pwkb0vdbu5d5t8.rcgu.o)'
[ 1076] 00027ac8 66 (N_OSO) 03 0001
'target/debug/deps/libspice21-1f365d6b281ad2bf.rlib(spice21-1f365d6b281ad2bf.16uddp6gzdci0bwn.rcgu.o)'
# ...
# about 150 others
```
And confirming this is not an issue with the IDE plug-in, setting the same
breakpoints via LLDB command also fails:
```
break set --file src/main.rs --line 5
Breakpoint 7: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
```
All of this is on MacOS, using the stable Rust compiler and LLDB 11.
First time bug-filer here, please let me know what info will help.
--
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 36215] LLD COFF handles /tsaware incorrectly
https://bugs.llvm.org/show_bug.cgi?id=36215 Petr Penzin changed: What|Removed |Added CC||penzin@gmail.com Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Petr Penzin --- /tsaware should on by default for console applications: > The /TSAWARE option is enabled by default for Windows and console > applications. See /SUBSYSTEM and /VERSION for information. See: https://docs.microsoft.com/en-us/cpp/build/reference/tsaware-create-terminal-server-aware-application?view=msvc-160#remarks (closer to the end of the section). -- 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 48030] New: [ItaniumCXXABI] TLS variable access wrapper optimization causes initializer function alias to be undefined (0)
https://bugs.llvm.org/show_bug.cgi?id=48030 Bug ID: 48030 Summary: [ItaniumCXXABI] TLS variable access wrapper optimization causes initializer function alias to be undefined (0) Product: clang Version: trunk Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: wolfgang_p...@playstation.sony.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Created attachment 24116 --> https://bugs.llvm.org/attachment.cgi?id=24116&action=edit Test case The following commit seems to have caused a serious issue wrt the interaction of global initializers and the wrapper functions to access thread-local variables: commit 00223827a952f66e7426c9881a2a4229e59bb019 Author: Richard Smith Date: Thu Sep 12 20:00:24 2019 + Improve code generation for thread_local variables: Summary: * Don't bother using a thread wrapper when the variable is known to have constant initialization. * Emit the thread wrapper as discardable-if-unused in TUs that don't contain a definition of the thread_local variable. * Don't emit the thread wrapper at all if the thread_local variable is unused and discardable; it will be emitted by all TUs that need it. Reviewers: rjmccall, jdoerfert Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67429 llvm-svn: 371767 Given the code attached (in "a.h"), the compiler does not generate a thread-local access wrapper function for the static member TLS::mData. It also does not generate a definition for the variable's initializer function's alias. However, it still emits the initializer function itself as part of a comdat group that encompasses all sections needed for its initialization. Given a second translation unit that does have a definition for the wrapper function as well as a comdat group to contain the variable's initializer, it is possible that the linker then picks the comdat group from the TU that does not have the definition for the (weak) initializer function alias. In this case the call to the initializer function in the wrapper function can get fixed up to call location 0, leading to a crash. The attached source demonstrates the problem on Linux. The test either runs or crashes depending on the order of the files on the link line: sh -x compile_and_run + CLANG=/home/test/build/llvm/git/mono-repo/llvm-RelWithDebInfo/bin/clang + /home/test/build/llvm/git/mono-repo/llvm-RelWithDebInfo/bin/clang -I. main.cpp a.cpp -o test1 + /home/test/build/llvm/git/mono-repo/llvm-RelWithDebInfo/bin/clang -I. a.cpp main.cpp -o test2 + ./test1 entering main returning + ./test2 entering main Segmentation fault (core dumped) -- 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 42474] [meta] 9.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=42474 Bug 42474 depends on bug 42513, which changed state. Bug 42513 Summary: Friend function declarations hidden in qualifed name lookup (regression introduced by commit r350505) https://bugs.llvm.org/show_bug.cgi?id=42513 What|Removed |Added Status|REOPENED|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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 42513] Friend function declarations hidden in qualifed name lookup (regression introduced by commit r350505)
https://bugs.llvm.org/show_bug.cgi?id=42513
Richard Smith changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Richard Smith ---
The new testcase is also rejected by GCC 10 onwards. But it accepts with this
change:
- if (auto i = GetInstance())
+ if (auto i = GetInstanceImpl((X1*)nullptr)())
whereas Clang rejects, saying:
:59:16: error: function 'GetInstanceImpl' with deduced return type
cannot be used before it is defined
if (auto i = GetInstanceImpl((X1*)nullptr)())
^
... which gives a suggestion as to what's going wrong. Here's a reduced
testcase:
template struct T { friend auto f(X*) {} };
struct X1 { friend auto f(X1*); };
template struct T;
void g() { f((X1*)nullptr); }
It turns out that when looking for a definition to instantiate in order to
resolve an undeduced return type, we didn't check for the case of a function
for which a different redeclaration was instantiated from a friend definition.
Fixed in dd8297b0669f8e69b03ba40171b195b5acf0f963.
--
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 47800] [meta] 11.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=47800 Bug 47800 depends on bug 47090, which changed state. Bug 47090 Summary: icmp gives inconsistent result for unnamed functions https://bugs.llvm.org/show_bug.cgi?id=47090 What|Removed |Added Status|REOPENED|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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47090] icmp gives inconsistent result for unnamed functions
https://bugs.llvm.org/show_bug.cgi?id=47090 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED Fixed By Commit(s)|d751f86 |d751f86 38399ced95b --- Comment #9 from Tom Stellard --- Merged: 38399ced95b -- 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 47935] BPF: backport commit 31611721686760fe59c91a84b025e4dee94d1662: fix incorrect DAG2DAG load optimization
https://bugs.llvm.org/show_bug.cgi?id=47935 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|31611721686760fe59c91a84b02 |31611721686760fe59c91a84b02 |5e4dee94d1662 |5e4dee94d1662 1ff84a04aeb Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom Stellard --- Merged: 1ff84a04aeb -- 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 47800] [meta] 11.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=47800 Bug 47800 depends on bug 47935, which changed state. Bug 47935 Summary: BPF: backport commit 31611721686760fe59c91a84b025e4dee94d1662: fix incorrect DAG2DAG load optimization https://bugs.llvm.org/show_bug.cgi?id=47935 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47800] [meta] 11.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=47800 Bug 47800 depends on bug 48000, which changed state. Bug 48000 Summary: Merge ae73091f30245852817c5c0af050a5a731dee50a into 11.0.1 https://bugs.llvm.org/show_bug.cgi?id=48000 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 48000] Merge ae73091f30245852817c5c0af050a5a731dee50a into 11.0.1
https://bugs.llvm.org/show_bug.cgi?id=48000 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|ae73091f30245852817c5c0af05 |ae73091f30245852817c5c0af05 |0a5a731dee50a |0a5a731dee50a 83716db47f9 --- Comment #1 from Tom Stellard --- Merged: 83716db47f9 -- 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 47917] Provide tarballs for libclc alongside LLVM releases
https://bugs.llvm.org/show_bug.cgi?id=47917 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|139785dc98ae94717eebaed083e |139785dc98ae94717eebaed083e |eaad5d775b495 |eaad5d775b495 8fc424f26bf Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Tom Stellard --- Merged: 8fc424f26bf -- 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 47800] [meta] 11.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=47800 Bug 47800 depends on bug 47917, which changed state. Bug 47917 Summary: Provide tarballs for libclc alongside LLVM releases https://bugs.llvm.org/show_bug.cgi?id=47917 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 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
