[llvm-bugs] [Bug 51685] New: Crash evaluating expression
https://bugs.llvm.org/show_bug.cgi?id=51685 Bug ID: 51685 Summary: Crash evaluating expression Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: l...@martijnotto.nl CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org When using lldb, it always fails evaluting an expression. Other things work normally, I can set breakpoints, and they're correctly triggered, but doing anything like `p something` always fails, no matter where in the program I do it or what the expression is. The stack trace: error: need to add support for DW_TAG_base_type 'auto' encoded with DW_ATE = 0x0, bit_size = 0 PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: lldb ./build/Debug/Arena 1. HandleCommand(command = "p getServer()") 2. :43:16: current parser token '$__lldb_expr' #0 0x7f3d5f1d69b3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xc0a9b3) #1 0x7f3d5f1d4d60 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xc08d60) #2 0x7f3d5f1d6e4f (/lib/x86_64-linux-gnu/libLLVM-13.so.1+0xc0ae4f) #3 0x7f3d6883a140 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14140) #4 0x7f3d6505b464 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xe6d464) #5 0x7f3d6505b7f7 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xe6d7f7) #6 0x7f3d6505918d clang::DeclContext::removeDecl(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xe6b18d) #7 0x7f3d64f2da72 clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd3fa72) #8 0x7f3d64f5646d clang::ASTImporter::ImportDefinition(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd6846d) #9 0x7f3d6830e5ac (/lib/x86_64-linux-gnu/liblldb-13.so.1+0xb525ac) #10 0x7f3d64f51dcd clang::ASTImporter::Import(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd63dcd) #11 0x7f3d64f2d5ec clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd3f5ec) #12 0x7f3d64f5646d clang::ASTImporter::ImportDefinition(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd6846d) #13 0x7f3d6830e5ac (/lib/x86_64-linux-gnu/liblldb-13.so.1+0xb525ac) #14 0x7f3d64f51dcd clang::ASTImporter::Import(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd63dcd) #15 0x7f3d64f2d5ec clang::ASTNodeImporter::ImportDeclContext(clang::DeclContext*, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd3f5ec) #16 0x7f3d64f5646d clang::ASTImporter::ImportDefinition(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd6846d) #17 0x7f3d6830e5ac (/lib/x86_64-linux-gnu/liblldb-13.so.1+0xb525ac) #18 0x7f3d64f51dcd clang::ASTImporter::Import(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd63dcd) #19 0x7f3d68309f52 (/lib/x86_64-linux-gnu/liblldb-13.so.1+0xb4df52) #20 0x7f3d68315fc0 (/lib/x86_64-linux-gnu/liblldb-13.so.1+0xb59fc0) #21 0x7f3d65047a63 clang::RecordDecl::LoadFieldsFromExternalStorage() const (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xe59a63) #22 0x7f3d650479cc clang::RecordDecl::field_begin() const (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xe599cc) #23 0x7f3d6505d21d clang::CXXRecordDecl::setBases(clang::CXXBaseSpecifier const* const*, unsigned int) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xe6f21d) #24 0x7f3d64f2d008 clang::ASTNodeImporter::ImportDefinition(clang::RecordDecl*, clang::RecordDecl*, clang::ASTNodeImporter::ImportDefinitionKind) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd3f008) #25 0x7f3d64f4094c clang::ASTNodeImporter::VisitClassTemplateSpecializationDecl(clang::ClassTemplateSpecializationDecl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd5294c) #26 0x7f3d64f50ce6 (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd62ce6) #27 0x7f3d64f50c87 clang::ASTImporter::ImportImpl(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd62c87) #28 0x7f3d6830e5ea (/lib/x86_64-linux-gnu/liblldb-13.so.1+0xb525ea) #29 0x7f3d64f51dcd clang::ASTImporter::Import(clang::Decl*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd63dcd) #30 0x7f3d64f2ac15 clang::ASTNodeImporter::VisitRecordType(clang::RecordType const*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd3cc15) #31 0x7f3d64f5132f (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd6332f) #32 0x7f3d64f510a0 clang::ASTImporter::Import(clang::Type const*) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd630a0) #33 0x7f3d64f303b9 clang::ASTNodeImporter::VisitTypedefNameDecl(clang::TypedefNameDecl*, bool) (/lib/x86_64-linux-gnu/libclang-cpp.so.13+0xd423b9) #34 0x7f3d64f50e85
[llvm-bugs] [Bug 51686] New: No exception is thrown when an invalid character range (e.g., [b-a]) is included.
https://bugs.llvm.org/show_bug.cgi?id=51686
Bug ID: 51686
Summary: No exception is thrown when an invalid character range
(e.g., [b-a]) is included.
Product: libc++
Version: 12.0
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Standards Issues
Assignee: unassignedclangb...@nondot.org
Reporter: w.kens...@fujitsu.com
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
---
#include
#include
#include
static bool error_range_thrown(const char *pat)
{
bool result = false;
try {
std::regex re(pat);
} catch (const std::regex_error &ex) {
puts("regex_error");
fflush(stdout);
result = (ex.code() == std::regex_constants::error_range);
}
return result;
}
int main(int, char**)
{
assert(error_range_thrown("([b-a])"));
}
---
This program is created using the regular expression sample described in the
C++ language standard, but it did not throw an exception (as expected).
(e.g., Table 132 in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf)
I've confirmed that this problem can be reproduced using clang 13.0.0 "[C++]
clang HEAD 13.0.0 (https://github.com/llvm/llvm-project.git
c4ed142e695f14ba5675ec6d12226ee706329a0f)" on Wandbox (https://wandbox.org/).
This code throws the exception on gcc-10.1.0 (or other gcc version).
--
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 51687] New: [llvm-exegesis] Analysis tests should run even without libpfm
https://bugs.llvm.org/show_bug.cgi?id=51687 Bug ID: 51687 Summary: [llvm-exegesis] Analysis tests should run even without libpfm Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-exegesis Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: clement.cour...@gmail.com, gchate...@google.com, llvm-bugs@lists.llvm.org The tests in llvm-project\llvm\test\tools\llvm-exegesis\ include a mixture of tests for all the modes supported by llvm-exegesis (uops, latency, inverse_throughput and analysis). Only the first 3 modes require llvm-exegesis to be built with libpfm to actually investigate the hardware. The analysis mode tests should be run in all cases where the relevant target is supported. -- 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 49198] Wrong usage of __dso_handle in user code leads to a compiler crash.
https://bugs.llvm.org/show_bug.cgi?id=49198 Andrew Savonichev changed: What|Removed |Added Status|NEW |RESOLVED CC||andrew.savonic...@gmail.com Resolution|--- |FIXED --- Comment #1 from Andrew Savonichev --- Fixed by D101156: [Clang] Support a user-defined __dso_handle https://reviews.llvm.org/D101156 -- 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 51688] New: Please backport c9948e9254fb to llvm13
https://bugs.llvm.org/show_bug.cgi?id=51688 Bug ID: 51688 Summary: Please backport c9948e9254fb to llvm13 Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: vvasi...@cern.ch CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk, tstel...@redhat.com Please backport commit c9948e9254fbb6ea00f66c7b4542311d21e060be (HEAD -> main, origin/main) Author: Vassil Vassilev Date: Tue Aug 31 15:19:17 2021 + [clang-repl] Install clang-repl This is essentially what D106813 was supposed to do but did not. Differential revision: https://reviews.llvm.org/D108919 This way clang-repl will become part of the llvm13 release. The biggest impact from this seems to be that it increases the release size of roughly the size of the clang binary. -- 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 48880] Confusing error message for unknown argument
https://bugs.llvm.org/show_bug.cgi?id=48880 Owen Reynolds changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||gbrey...@gmail.com --- Comment #1 from Owen Reynolds --- Fixed in commit 71d7fed3bc2ad6c22729d446526a59fcfd99bd03 -- 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 51680] [SCEV] After 14d8f1546a0, via SCEV, Assertion failed: (isa(Val) && "cast() argument of incompatible type!"), function cast, file llvm/include/llvm/Support/Casting.h, lin
https://bugs.llvm.org/show_bug.cgi?id=51680
listm...@philipreames.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from listm...@philipreames.com ---
Should be fixed with:
commit 9b45fd909ffa754acbb4e927bc2d55c7ab0d4e3f (HEAD -> main, origin/main)
Author: Philip Reames
Date: Tue Aug 31 09:17:36 2021 -0700
[AlignFromAssume] Bailout w/non-constant alignments (pr51680)
This is a bailout for pr51680. This pass appears to assume that the
alignment operand to an align tag on an assume bundle is constant. This
doesn't appear to be required anywhere, and clang happily generates
non-constant alignments for cases such as this case taken from the bug report:
// clang -cc1 -triple powerpc64-- -S -O1 opal_pci-min.c
extern int a[];
long *b;
long c;
void *d(long, int *, int, long, long, long)
__attribute__((__alloc_align__(6)));
void e() {
b = d(c, a, 0, 0, 5, c);
b[0] = 0;
}
This was exposed by a SCEV change which allowed a non-constant alignment to
reach further into the pass' code. We could generalize the pass, but for now,
let's fix the crash.
--
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 37798 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic
Updates: Status: WontFix Comment #1 on issue 37798 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::Sema::EmitCurrentDiagnostic https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37798#c1 ClusterFuzz testcase 5766091306041344 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 51689] New: Clang introduces invalid padding for empty base classes
https://bugs.llvm.org/show_bug.cgi?id=51689
Bug ID: 51689
Summary: Clang introduces invalid padding for empty base
classes
Product: clang
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: CUDA
Assignee: unassignedclangb...@nondot.org
Reporter: joac...@joameyer.de
CC: llvm-bugs@lists.llvm.org
Following up on issues reported in
https://github.com/illuhad/hipSYCL/issues/620#issuecomment-908400489 we tracked
the issue down to an invalid struct layout with multiple empty base classes.
https://godbolt.org/z/xoa9P38vW
The example introduces invalid padding on Windows hosts, thus leading to issues
when using the `has_wrong_size` class in CUDA or similar contexts, where the
layout of the class is of high importance.
Note that the device code has no padding and would compile fine.
#include
class test0{};
class test1{};
class test2{public: uint64_t s;};
class works : public test0, public test2{};
static_assert(__builtin_offsetof(works, s) == 0, "offset");
static_assert(sizeof(works) == sizeof(uint64_t), "size wrong");
class has_wrong_size : public test0, public test1, public test2{};
//#ifdef __CUDACC__ // is fine on CUDA
static_assert(__builtin_offsetof(has_wrong_size, s) == 0, "offset");
static_assert(sizeof(has_wrong_size) == sizeof(uint64_t), "size wrong");
//#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 51690] New: Merge 9b45fd909ffa into 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=51690
Bug ID: 51690
Summary: Merge 9b45fd909ffa into 13.0.0
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Please merge https://github.com/llvm/llvm-project/commit/9b45fd909ffa ("
[AlignFromAssume] Bailout w/non-constant alignments (pr51680) ") into 13.0.0.
This fixes bug 51680, which is an assertion failure when using the
__alloc_align__() attribute.
--
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 51634] Issue with passing expression to inline assembly in Linux kernel
https://bugs.llvm.org/show_bug.cgi?id=51634 Nathan Chancellor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Nathan Chancellor --- Thanks Eli, we have fixed this on the kernel side so I'll mark this as invalid. https://lore.kernel.org/r/20210831132720.881643-1-...@ellerman.id.au/ -- 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 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 51634, which changed state. Bug 51634 Summary: Issue with passing expression to inline assembly in Linux kernel https://bugs.llvm.org/show_bug.cgi?id=51634 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51691] New: [mips] After a26f1bf67ec, Bad machine code: Using an undefined physical register
https://bugs.llvm.org/show_bug.cgi?id=51691
Bug ID: 51691
Summary: [mips] After a26f1bf67ec, Bad machine code: Using an
undefined physical register
Product: new-bugs
Version: trunk
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: dimi...@andric.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
This backend error appeared when compiling the FreeBSD base system for mips or
mips64 with clang 13:
*** Bad machine code: Using an undefined physical register ***
- function:checkfstab
- basic block: %bb.27 if.end51 (0x80768a568)
- instruction: %161:gpr32 = COPY $v1
- operand 1: $v1
fatal error: error in backend: Found 1 machine code errors.
Bisection shows this error starts occurring after
https://github.com/llvm/llvm-project/commit/a26f1bf67ec ("[PassManager] Run
additional LICM before LoopRotate "), so I am suspecting that this exposes a
latent bug somewhere in the Mips backend? (As these test cases seem to work
fine on other architectures.)
Minimized test case for 32-bit mips:
// clang -cc1 -triple mips-- -S -mrelocation-model static -target-cpu mips2 -O2
preen-min.c
typedef struct {
int a[0];
} b;
b c;
extern _Thread_local b *d;
int e, f, ay;
struct {
int g;
int h;
} * k;
char *ax;
b *l() {
if (d)
return d;
return &c;
}
int m() {
int i = 0, j = i;
f = l()->a[j];
return e;
}
char *n();
void o();
void q() {
if (k)
o(&k->h, k);
}
void o(char *r, int *s, int *t) {
char aw = *s;
char *p = n();
if (p)
p = &aw;
for (; *p && m(); p++)
for (; 0; ay = *t)
;
ax = r;
}
Minimized test case for 64-bit mips (looking very similar, though derived from
a very different source file):
// clang -cc1 -triple mips64-- -S -target-cpu mips3 -O2
-ftls-model=initial-exec tw-min.c
typedef struct {
int a[0];
} b;
b *c;
extern _Thread_local b *d;
int e, f;
b *g() {
if (d)
return d;
return c;
}
int h(j) {
int i = j;
e = g()->a[i];
return 1;
}
void k() {
int *a;
for (a = 0; f;)
if (0 ?: h) {
int b;
a++;
if (*a) {
b = 0;
a++;
}
for (; h(*a);)
;
}
}
--
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 51655] Bad machine code: Live segment doesn't end at a valid instruction
https://bugs.llvm.org/show_bug.cgi?id=51655 Stanislav Mekhanoshin changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #6 from Stanislav Mekhanoshin --- Fixed by https://reviews.llvm.org/rGd170945bb2b3a0855cea115d31d688b85ddf3dc5 -- 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 51692] New: symlinks creation is broken in LLVM 13 Windows build
https://bugs.llvm.org/show_bug.cgi?id=51692 Bug ID: 51692 Summary: symlinks creation is broken in LLVM 13 Windows build Product: Build scripts Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: cmake Assignee: unassignedb...@nondot.org Reporter: arina.neshlya...@intel.com CC: llvm-bugs@lists.llvm.org LLVM branch origin/release/13.x. LLVM is built inside Github Actions "windows-2019" image using the following command: cmake -Thost=x64 -G "Visual Studio 16" -DCMAKE_INSTALL_PREFIX="..\bin-13.0" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang" -DLLVM_ENABLE_DUMP=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_INSTALL_UTILS=ON -DLLVM_TARGETS_TO_BUILD=AArch64\;ARM\;X86 -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly -DLLVM_LIT_TOOLS_DIR="C:\gnuwin32\bin" ..\llvm-13.0/llvm The build and installation are reported as successful but symlinks are broken. 08/26/2021 02:59 AM 0 clang++.exe 08/26/2021 02:59 AM 0 llvm-lib.exe 08/26/2021 02:59 AM 0 clang-cl.exe 08/26/2021 02:59 AM 0 clang-cpp.exe 08/26/2021 02:43 AM91,814,912 clang.exe There is no issue before commit f37ea62e57b5e0e7b52102a2254288e205bfef89. So it seems that "cmake -E create_symlink" command was not successful but error code was not returned. List of the tools installed inside "windows-2019" can be found here: https://github.com/actions/virtual-environments/blob/main/images/win/Windows2019-Readme.md You can access LLVM artifacts from mentioned build in Github Actions here: https://github.com/ispc/ispc/suites/3636454262/artifacts/88150157 Link to the LLVM build log: https://github.com/ispc/ispc/runs/3467483548 -- 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 51693] New: UBSan reports an error and incorrect alignment when global new returns an offset pointer
https://bugs.llvm.org/show_bug.cgi?id=51693 Bug ID: 51693 Summary: UBSan reports an error and incorrect alignment when global new returns an offset pointer Product: compiler-rt Version: 12.0 Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: ubsan Assignee: unassignedb...@nondot.org Reporter: lambert.cl...@yahoo.fr CC: llvm-bugs@lists.llvm.org Hello! I found that ubsan will report an incorrect alignment for a type in case it is allocated with the global operator new (without alignment), if we have it return an offset ptr. I wrote a small repro: https://godbolt.org/z/n8Yh8eoaE The type is aligned on 8 bytes (verified by static_assert on its alignof), but ubsan reports: "constructor call on misaligned address 0x02af8fd8 for type 'Param', which requires 16 byte alignment". Now I suppose changing the ptr returned by new that way breaks the __STDCPP_DEFAULT_NEW_ALIGNMENT__, but in the specs in [basic.stc.dynamic.allocation] it says for the non-aligned, non array new: "Otherwise, the storage is aligned for any object that does not have new-extended alignment and is of the requested size", which is pretty vague. I would either expect to get an error message to indicate that break, or nothing, because in the end the pointer returned by new is 8 bytes aligned, and matches the 8 bytes alignment requirement of the type. I think the issue comes from this line: https://github.com/llvm/llvm-project/blob/4f7fb13f87e10bd2cd89ccf2be70b026032237a7/clang/lib/CodeGen/CGExprCXX.cpp#L1737 Instead of the allocator alignment result.getAlignment(), it should be the type alignment allocAlign. I've tried it, and ran the tests, the error goes away and the tests pass. Open to ideas :) 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 51694] New: [missed optimization opportunity] clang still generates code for empty std::map iteration
https://bugs.llvm.org/show_bug.cgi?id=51694 Bug ID: 51694 Summary: [missed optimization opportunity] clang still generates code for empty std::map iteration Product: clang Version: 11.0 Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: y...@tsoft.com CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk Created attachment 25208 --> https://bugs.llvm.org/attachment.cgi?id=25208&action=edit testcase.cpp The attached testcase iterates through the std::map object with empty for-body. clang-14 still generates some code in this function when it should be empty. Replacing the type of the argument with std::vector correctly leads to an empty function. -- 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 51689] Clang introduces invalid padding for empty base classes
https://bugs.llvm.org/show_bug.cgi?id=51689 Joachim Meyer changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Joachim Meyer --- Closing and leaving this as a reference: https://devblogs.microsoft.com/cppblog/optimizing-the-layout-of-empty-base-classes-in-vs2015-update-2-3/ One can use `__declspec(empty_bases)` to work around the issue right now and a future major version of MSVC might change the ABI to do that by default (although there hasn't been a new major version since then). Still wondering whether it might be possible, to not just silently miscompile when using the differently layouted as parameters to CUDA kernels. -- 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 51695] New: Clang not emitting destructor call when assignment constructed with list
https://bugs.llvm.org/show_bug.cgi?id=51695
Bug ID: 51695
Summary: Clang not emitting destructor call when assignment
constructed with list
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: lxf...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
In the following code: https://godbolt.org/z/TK7ersK1M
#include
#include
void doSomething();
class FooClass {
public:
FooClass() noexcept : ptr_() {}
FooClass(FooClass&& other) noexcept
: ptr_(std::exchange(other.ptr_, {})) {}
~FooClass() {
doSomething();
}
FooClass& operator=(FooClass other) noexcept {
std::swap(ptr_, other.ptr_);
return *this;
}
private:
void *ptr_;
};
template
class WrapperClass {
public:
void run() noexcept {
wrapper_ = {};
}
private:
FooClass wrapper_;
};
void foo(WrapperClass &A) {
A.run();
}
When compiled with either GCC (any std version) or Clang with C++14, the line
"wrapper_ = {};" in WrapperClass::run() will always generate a destructor call
in the end, which is expected.
However when compiled with Clang C++17, the destructor call is not generated,
which seems wrong to me.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51475] lld-macho doesn't force-load ObjC archive members before resolving their symbols
https://bugs.llvm.org/show_bug.cgi?id=51475
Vy Nguyen changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|--- |FIXED
--- Comment #15 from Vy Nguyen ---
Repro case:
// Foo.h
#import
@interface Foo : NSObject
@end
// Foo.m
#import "Foo.h"
@implementation Foo {
NSString* _privateDupSym;
}
- (void)prepareForReuse {
_privateDupSym = nil;
}
@end
Put both files in a directory called "one".
Copy the dir to "two".
clang -c -ObjC one/Foo.m -o one/Foo.o
clang -c -ObjC two/Foo.m -o two/Foo.o
llvm-ar r libDup.a one/Foo.o two/Foo.o
LD64 allows linking this.
ld -demangle -dynamic -bundle -arch "x86_64" -platform_version macos 10.15
11.0 -syslibroot
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
-ObjC -lc++ -lobjc -lSystem -framework Foundation libDup.a
LLD doesn't:
$ ../bin/ld64.lld.darwinnew -demangle -dynamic -bundle -arch "x86_64"
-platform_version macos 10.15 11.0 -syslibroot
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
-ObjC -lc++ -lobjc -lSystem -framework Foundation libDup.a
ld64.lld.darwinnew: warning: libDup.a(Foo.o) has version 11.0.0, which is newer
than target minimum of 10.15
ld64.lld.darwinnew: warning: libDup.a(Foo.o) has version 11.0.0, which is newer
than target minimum of 10.15
ld64.lld.darwinnew: error: duplicate symbol: _OBJC_METACLASS_$_Foo
>>> defined in libDup.a(Foo.o)
>>> defined in libDup.a(Foo.o)
ld64.lld.darwinnew: error: duplicate symbol: _OBJC_CLASS_$_Foo
>>> defined in libDup.a(Foo.o)
>>> defined in libDup.a(Foo.o)
---
However, it seems this is a bug in LD64. It keeps a map symbol=>ar member, and
it *iterates* that for -ObjC. (So it discards duplicates symbols).
(Also if you put -force_load or -all_load the archive, then it'd also complain
about the duplicate symbols).
We probably don't want LLD to do this.
I'll re-close this bug - sorry!
--
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 51696] New: enable_if "requirement not satisfied" diagnostics could be more robust and general
https://bugs.llvm.org/show_bug.cgi?id=51696
Bug ID: 51696
Summary: enable_if "requirement not satisfied" diagnostics
could be more robust and general
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: arthur.j.odw...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
// https://godbolt.org/z/E5d63q77E
cat >test.cpp < struct enable_if { using type = T; };
template struct enable_if {};
// LIES AND DECEPTION
template using enable_if_t = typename enable_if::type;
template auto f() -> enable_if_t {}
void test() {
f();
}
EOF
clang++ -c test.cpp
test.cpp:10:5: error: no matching function for call to 'f'
f();
^~~
test.cpp:7:24: note: candidate template ignored: requirement 'true' was not
satisfied [with T = char]
template auto f() -> enable_if_t {}
^
The problem is that the diagnostic is looking for the specific names
`enable_if` and `enable_if_t`, and then *assuming* that if the templates have
those names (regardless of namespace), their parameters must follow the
expected pattern.
It would be nicer if Clang could follow the outline I sketched in
https://reviews.llvm.org/D108216 :
> Well, remember that our _EnableIf has a different shape from the standard
> enable_if_t. Ours is _MetaBase::_EnableIfImpl, whereas enable_if_t
> is enable_if::type. So I think the criterion would be something
> like "We failed to find a member in a class template of the form
> template<[...], bool, [...]>, where that bool parameter is false,
> and where, if the bool parameter had been true, we would have found
> such a member." If that's too backtracky (Clang sucks at
> backtracking/hypotheticals), we could say "We failed to find a member
> in a class template of the form template<[...], bool, [...]>,
> where that bool parameter is false, and where the class template
> has at least one partial or explicit specialization." I would not
> look at the name of the member, nor the name of the class, nor
> the reason-we're-looking-for-that-member (e.g. the name of the
> alias template).
If Clang could do this, then not only would it not get tricked by stupid
contrived examples like mine above, but also it would be able to detect
"requirements" even when they were implemented in SCARY-template ways such as
the above-mentioned _MetaBase::_EnableIfImpl. As long as there's *a* bool
argument, that is false, and where if it were true we would have found a
member, that should be good enough to trigger Clang's special-case diagnostics
about "requirement was not satisfied".
Even though this bug report is phrased in terms of a "bad diagnostic on
contrived input," *really* what I'm hoping to get out of it is "good
diagnostics on realistic input" (and specifically, on libc++'s _EnableIf). My
contrived example merely demonstrates that the existing code in Clang cannot be
defended on the grounds of "being safely conservative," in case anyone was
going to try that.
--
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 51697] New: clang-13 regression: crash if compile with -fsave-optimization-record=bitstream
https://bugs.llvm.org/show_bug.cgi?id=51697
Bug ID: 51697
Summary: clang-13 regression: crash if compile with
-fsave-optimization-record=bitstream
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: npick...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
= Symptom
clang will crash on compile any program with
-fsave-optimization-record=bitstream.
= Version
Both llvm 13 branch and main branch will crash
$ clang -v
clang version 13.0.0 (g...@github.com:llvm/llvm-project.git
0ec5fc44ee05ea47e353e6a7eb5c2acc84004515)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang -v
clang version 14.0.0 (g...@github.com:llvm/llvm-project.git
c1184ca6eb97e0ac5f7b6cdcc99e3905d27f9d95)
Target: x86_64-unknown-linux-gnu
Thread model: posix
= How to reproduce
$ cat x.c
int foo(){return 0;}
$ clang x.c -fsave-optimization-record=bitstream -target x86_64-linux-gnu
= error message
0. Program arguments: /scratch1/kitoc/llvm-workspace/build/bin/clang-13
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all
--mrelax-relocations -disable-free -main-file-name x.c -mrelocation-model
static -mframe-pointer=all -fmath-errno -fno-rounding-math
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic
-debug-info-kind=line-tables-only -debugger-tuning=gdb
-fcoverage-compilation-dir=/home/kitoc/llvm-workspace/build -resource-dir
/scratch1/kitoc/llvm-workspace/build/lib/clang/13.0.0 -internal-isystem
/scratch1/kitoc/llvm-workspace/build/lib/clang/13.0.0/include -internal-isystem
/usr/local/include -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir=/home/kitoc/llvm-workspace/build -ferror-limit 19
-fgnuc-version=4.2.1 -fcolor-diagnostics -opt-record-file x.opt.bitstream
-opt-record-format bitstream -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o
/tmp/x-208687.o -x c x.c
1. parser at end of file
2. Code generation
#0 0x557c35c91a02 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Unix/Signals.inc:565:0
#1 0x557c35c91ab9 PrintStackTraceSignalHandler(void*)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Unix/Signals.inc:632:0
#2 0x557c35c8f76d llvm::sys::RunSignalHandlers()
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Signals.cpp:97:0
#3 0x557c35c91383 SignalHandler(int)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/Support/Unix/Signals.inc:407:0
#4 0x7f5a971e2980 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
#5 0x7f5a95e0ffb7 raise
/build/glibc-S9d2JN/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
#6 0x7f5a95e11921 abort /build/glibc-S9d2JN/glibc-2.27/stdlib/abort.c:81:0
#7 0x7f5a95e0148a __assert_fail_base
/build/glibc-S9d2JN/glibc-2.27/assert/assert.c:89:0
#8 0x7f5a95e01502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#9 0x557c3574efd2 llvm::MCStreamer::SwitchSection(llvm::MCSection*,
llvm::MCExpr const*)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/MC/MCStreamer.cpp:1211:0
#10 0x557c36f337a3
llvm::AsmPrinter::emitRemarksSection(llvm::remarks::RemarkStreamer&)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1710:0
#11 0x557c36f33bc9 llvm::AsmPrinter::doFinalization(llvm::Module&)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1771:0
#12 0x557c350dc3ff llvm::FPPassManager::doFinalization(llvm::Module&)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1503:0
#13 0x557c350dc9a4 (anonymous
namespace)::MPPassManager::runOnModule(llvm::Module&)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1590:0
#14 0x557c350d77f9 llvm::legacy::PassManagerImpl::run(llvm::Module&)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:542:0
#15 0x557c350dcfc3 llvm::legacy::PassManager::run(llvm::Module&)
/home/kitoc/llvm-workspace/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1682:0
#16 0x557c360d462f (anonymous
namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction,
std::unique_ptr >)
/home/kitoc/llvm-workspace/llvm-project/clang/lib/CodeGen/BackendUtil.cpp:1499:0
#17 0x557c360d57ee clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::HeaderSearchOptions const&, clang::CodeGenOptions const&,
clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef,
llvm::Module*, clang::BackendA
[llvm-bugs] [Bug 51630] [M68k] Cherry-pick f659b6b to workaround a GCC bug
https://bugs.llvm.org/show_bug.cgi?id=51630 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|f659b6b |f659b6b 0ec5fc44ee05 --- Comment #1 from Tom Stellard --- Merged: 0ec5fc44ee05 -- 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 51236] [meta] 13.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=51236 Bug 51236 depends on bug 51630, which changed state. Bug 51630 Summary: [M68k] Cherry-pick f659b6b to workaround a GCC bug https://bugs.llvm.org/show_bug.cgi?id=51630 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 51236] [meta] 13.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=51236 Bug 51236 depends on bug 51497, which changed state. Bug 51497 Summary: [compiler-rt] Merge 6c0e6f91d7f02cecdf11efb26050c48680a806ce into 13.0.0 https://bugs.llvm.org/show_bug.cgi?id=51497 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 51625] [libomptarget][amdgpu] Merge 71ae2e0221a9 into 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=51625 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|71ae2e0221a9|71ae2e0221a9 ce268f0eb9e7 Resolution|--- |FIXED --- Comment #1 from Tom Stellard --- Merged: ce268f0eb9e7 -- 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 51497] [compiler-rt] Merge 6c0e6f91d7f02cecdf11efb26050c48680a806ce into 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=51497 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|6c0e6f91d7f02cecdf11efb2605 |6c0e6f91d7f02cecdf11efb2605 |0c48680a806ce |0c48680a806ce 65eb65c694f5 --- Comment #4 from Tom Stellard --- Merged: 65eb65c694f5 -- 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 51236] [meta] 13.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=51236 Bug 51236 depends on bug 51625, which changed state. Bug 51625 Summary: [libomptarget][amdgpu] Merge 71ae2e0221a9 into 13.0.0 https://bugs.llvm.org/show_bug.cgi?id=51625 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 51646] [M68k] Cherry-pick 8d3f112 to fix target layout
https://bugs.llvm.org/show_bug.cgi?id=51646 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)|8d3f112f0cdbed2311aead86bcd |8d3f112f0cdbed2311aead86bcd |72e763ad55255 |72e763ad55255 577cf27b7845 --- Comment #1 from Tom Stellard --- Merged: 577cf27b7845 -- 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 51236] [meta] 13.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=51236 Bug 51236 depends on bug 51646, which changed state. Bug 51646 Summary: [M68k] Cherry-pick 8d3f112 to fix target layout https://bugs.llvm.org/show_bug.cgi?id=51646 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 51651] [WebAssembly] FastISel miscompiles comparison used in different block
https://bugs.llvm.org/show_bug.cgi?id=51651 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|16086d47c0d0cd08ffae8e69a69 |16086d47c0d0cd08ffae8e69a69 |c88653e654d01 |c88653e654d01 d1dd1fb104a6 --- Comment #3 from Tom Stellard --- Merged: d1dd1fb104a6 -- 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 51236] [meta] 13.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=51236 Bug 51236 depends on bug 51651, which changed state. Bug 51651 Summary: [WebAssembly] FastISel miscompiles comparison used in different block https://bugs.llvm.org/show_bug.cgi?id=51651 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 51236] [meta] 13.0.0 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=51236 Bug 51236 depends on bug 51677, which changed state. Bug 51677 Summary: llvm.smul.fix.sat.i8(-128, -128, 0) equals -128 https://bugs.llvm.org/show_bug.cgi?id=51677 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 51677] llvm.smul.fix.sat.i8(-128, -128, 0) equals -128
https://bugs.llvm.org/show_bug.cgi?id=51677 Tom Stellard changed: What|Removed |Added Status|REOPENED|RESOLVED Fixed By Commit(s)|789f01283d52065b10049b58a32 |789f01283d52065b10049b58a32 |88c4abd1ef351 |88c4abd1ef351 d6a48141f284 Resolution|--- |FIXED --- Comment #12 from Tom Stellard --- Merged: d6a48141f284 -- 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 51698] New: [Linker] Merge 92f54e1c752253b5a17eb9ec7942f580d878f64d into 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=51698 Bug ID: 51698 Summary: [Linker] Merge 92f54e1c752253b5a17eb9ec7942f580d878f64d into 13.0.0 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: Linker Assignee: unassignedb...@nondot.org Reporter: pho...@chromium.org CC: llvm-bugs@lists.llvm.org, tstel...@redhat.com Blocks: 51236 Would it be possible to merge https://github.com/petrhosek/llvm-project/tree/fix-nodeduplicate into the 13.0.0 release branch? This addresses PR51394 which was reported by Sony as an issue affecting 13.0.0. It was addressed by 92f54e1c752253b5a17eb9ec7942f580d878f64d in the main branch but it doesn't cherry-pick cleanly into the release branch so I had to manually resolve conflicts in my own branch. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=51236 [Bug 51236] [meta] 13.0.0 Release Blockers -- 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 51699] New: LLVM 13 regression: x86_64 ran out of registers during register allocation with valgrind client request
https://bugs.llvm.org/show_bug.cgi?id=51699 Bug ID: 51699 Summary: LLVM 13 regression: x86_64 ran out of registers during register allocation with valgrind client request Product: new-bugs Version: trunk Hardware: All OS: All Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: and...@ziglang.org CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 25209 --> https://bugs.llvm.org/attachment.cgi?id=25209&action=edit test.ll To reproduce: clang-13 -c test.ll It gives: error: ran out of registers during register allocation However it worked in LLVM 12. This inline assembly is used to form a Valgrind Client Request. This bug found via the Zig programming language behavior test suite in the llvm13 branch. -- 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
