[llvm-bugs] [Bug 51532] LLDB crash when breakpoint in swift file
https://bugs.llvm.org/show_bug.cgi?id=51532 Raphael Isemann changed: What|Removed |Added CC||teempe...@gmail.com Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Raphael Isemann --- Hi Alex, thanks a lot for the bug report, but the Swift plugin for LLDB is not part of the LLVM project (even though Swift-LLDB's crash message implies that). You could file the bug report to bugs.swift.org (which has a "LLDB for Swift" component) or a bug with Apple as this crash is happening in the LLDB that is shipped with Xcode. -- 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 51533] New: [lldb] Merge 5033f0793fe6 and cf521e78dfd2 into 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=51533
Bug ID: 51533
Summary: [lldb] Merge 5033f0793fe6 and cf521e78dfd2 into 13.0.0
Product: lldb
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: dimi...@andric.com
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
Please merge https://github.com/llvm/llvm-project/commit/5033f0793fe6 ("[lldb]
Avoid unhandled Error in TypeSystemMap::GetTypeSystemForLanguage") and
https://github.com/llvm/llvm-project/commit/cf521e78dfd2 ("[lldb] Add tests for
TypeSystemMap::GetTypeSystemForLanguage") into 13.0.0.
The first commit fixes a problem where lldb can core dump if assertions are
disabled, and a TypeSystem object cannot be found or created at runtime. The
second commit adds tests for TypeSystemMap.
--
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 51535] New: why gotpcrel is generated after llvm 12?
https://bugs.llvm.org/show_bug.cgi?id=51535
Bug ID: 51535
Summary: why gotpcrel is generated after llvm 12?
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: kamleshbha...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, pengfei.w...@intel.com,
spatel+l...@rotateright.com
Consider below testcase
$cat test.ll
@arr = common global [8 x i8] zeroinitializer
define void @foo() {
entry:
call void @bar(i8* getelementptr inbounds ([8 x i8], [8 x i8]* @arr, i64 0,
i64 0))
ret void
}
declare void @bar(i8*)
$./clang test.ll -c -Xassembler -mrelax-relocations=no -mno-relax-all -S
warning: overriding the module target triple with x86_64-unknown-linux-gnu
[-Woverride-module]
1 warning generated.
$ cat test.s
.text
.file "test.ll"
.globl foo # -- Begin function foo
.p2align4, 0x90
.type foo,@function
foo:# @foo
.cfi_startproc
# %bb.0:# %entry
pushq %rax
.cfi_def_cfa_offset 16
movqarr@GOTPCREL(%rip), %rdi
callq bar@PLT
popq%rax
.cfi_def_cfa_offset 8
retq
.Lfunc_end0:
.size foo, .Lfunc_end0-foo
.cfi_endproc
# -- End function
.type arr,@object # @arr
.comm arr,8,1
.section".note.GNU-stack","",@progbits
.addrsig
.addrsig_sym bar
.addrsig_sym arr
As can be seen above GOTPCREL is generated for non pic code.
--
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 51536] New: [AMDGPU][MC][DOC] Invalid description of 8-bit DS offsets
https://bugs.llvm.org/show_bug.cgi?id=51536 Bug ID: 51536 Summary: [AMDGPU][MC][DOC] Invalid description of 8-bit DS offsets Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: d-...@mail.ru CC: llvm-bugs@lists.llvm.org 8-bit DS offset modifier description states that the valid syntax is "offset:...", however it should be "offset0:..." or "offset1:..." depending on modifier position. See https://llvm.org/docs/AMDGPUModifierSyntax.html#amdgpu-synid-ds-offset8 -- 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 51537] New: [concepts] [ice] deduction guide
https://bugs.llvm.org/show_bug.cgi?id=51537
Bug ID: 51537
Summary: [concepts] [ice] deduction guide
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: l...@marehr.dialup.fu-berlin.de
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Hi clang-team,
the following code ices:
```
template struct index_traits {
template using rebind = int;
};
template typename rebind> struct index_traits_has_rebind {
static constexpr bool value = true;
};
template
concept index_concept = requires(index_t a, index_t b) {
requires index_traits_has_rebind<
index_traits::template rebind>::value;
};
template
requires(index_concept) struct matrix_index {
constexpr matrix_index(index_t const, index_t const) noexcept;
};
template
matrix_index(index_t, index_t) -> matrix_index;
template struct coordinate_matrix {
using value_type = decltype(matrix_index{int{}, int{}});
};
```
https://godbolt.org/z/4hP6zjn7G
with the following error:
```
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: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o
/app/output.s -mllvm --x86-asm-syntax=intel -S
--gcc-toolchain=/opt/compiler-explorer/gcc-snapshot -fcolor-diagnostics
-fno-crash-diagnostics -std=c++20
1. :24:57: current parser token ')'
2. :23:27: parsing struct/union/class body 'coordinate_matrix'
#0 0x55cf9a14036f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x55cf9a13e230 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x34fe230)
#2 0x55cf9a08f218 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#3 0x7fb379ac73c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x55cf9c69f678 (anonymous
namespace)::MarkUsedTemplateParameterVisitor::TraverseTemplateName(clang::TemplateName)
SemaTemplateDeduction.cpp:0:0
#5 0x55cf9c69f945 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::TraverseTemplateArgumentLoc(clang::TemplateArgumentLoc
const&) SemaTemplateDeduction.cpp:0:0
#6 0x55cf9c69fe79 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::TraverseTypeLoc(clang::TypeLoc)
SemaTemplateDeduction.cpp:0:0
#7 0x55cf9c6a0483 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::TraverseNestedNameSpecifierLoc(clang::NestedNameSpecifierLoc)
SemaTemplateDeduction.cpp:0:0
#8 0x55cf9c6a96a4 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::TraverseDependentScopeDeclRefExpr(clang::DependentScopeDeclRefExpr*,
llvm::SmallVectorImpl,
llvm::PointerIntPairInfo > > >*) SemaTemplateDeduction.cpp:0:0
#9 0x55cf9c6952a1 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::dataTraverseNode(clang::Stmt*,
llvm::SmallVectorImpl,
llvm::PointerIntPairInfo > > >*) SemaTemplateDeduction.cpp:0:0
#10 0x55cf9c6962d9 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::TraverseStmt(clang::Stmt*,
llvm::SmallVectorImpl,
llvm::PointerIntPairInfo > > >*) (.part.5303)
SemaTemplateDeduction.cpp:0:0
#11 0x55cf9c6ac0a0 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::TraverseRequiresExpr(clang::RequiresExpr*,
llvm::SmallVectorImpl,
llvm::PointerIntPairInfo > > >*) SemaTemplateDeduction.cpp:0:0
#12 0x55cf9c694e01 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::dataTraverseNode(clang::Stmt*,
llvm::SmallVectorImpl,
llvm::PointerIntPairInfo > > >*) SemaTemplateDeduction.cpp:0:0
#13 0x55cf9c6962d9 clang::RecursiveASTVisitor<(anonymous
namespace)::MarkUsedTemplateParameterVisitor>::TraverseStmt(clang::Stmt*,
llvm::SmallVectorImpl,
llvm::PointerIntPairInfo > > >*) (.part.5303)
SemaTemplateDeduction.cpp:0:0
#14 0x55cf9c6ac69a clang::Sema::MarkUsedTemplateParameters(clang::Expr
const*, bool, unsigned int, llvm::SmallBitVector&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5a6c69a)
#15 0x55cf9c0ff84e substituteParameterMappings(clang::Sema&,
clang::NormalizedConstraint&, clang::ConceptDecl*,
llvm::ArrayRef, clang::ASTTemplateArgumentListInfo
const*) SemaConcept.cpp:0:0
#16 0x55cf9c104df4
clang::NormalizedConstraint::fromConstraintExpr(clang::Sema&,
clang::NamedDecl*, clang::Expr const*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x54c4df4)
#17 0x55cf9c10512a
clang::NormalizedConstraint::fromConstraintExprs(clang::Sema&,
clang::NamedDecl*, llvm::ArrayRef)
(/opt/compiler-explore
[llvm-bugs] [Bug 51538] New: pointer to member of forward declared class inside a template class causes a crash on Windows
https://bugs.llvm.org/show_bug.cgi?id=51538
Bug ID: 51538
Summary: pointer to member of forward declared class inside a
template class causes a crash on Windows
Product: clang
Version: 12.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jakub.lopuszan...@oracle.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
The following short code:
```
template struct a;
template struct c;
template class d {
class e;
typedef a> g;
class e {
int f;
friend d;
};
};
d<> rec_init_offsets_index;
```
crashes on Windows when compiled with (under GitBash):
$ '/c/Program Files/LLVM12.0.1/bin/clang.exe' -cc1 -gcodeview
-debug-info-kind=limited -fms-compatibility -emit-llvm small.cpp
I've tested 12.0.1, 11.0.0, 10.0.0, 8.0.1, 7.1.0 versions installed using
installers from your official website, and all of them crash.
Also, I've asked a coworker with Windows+clang12, and it crashes for him, too.
Finally, the code seems to compile just fine on linux
5.4.17-2011.6.2.el8uek.x86_64 with clang 11.0.0.
Also, please note that:
```
template struct a;
template struct c;
template class d {
class e {
int f;
friend d;
};
typedef a> g;
};
d<> rec_init_offsets_index;
```
(where I've moved `class e` definition sooner) compiles just fine.
The mimimized snippet was reduced from a 4MB source, but I guess it resembles
this part of the real code:
```
template
class dyn_buf_t {
public:
class block_t;
typedef UT_LIST_NODE_T(block_t) block_node_t;
typedef UT_LIST_BASE_NODE_T(block_t, m_node) block_list_t;
class block_t {
public:
block_t() {
ut_ad(MAX_DATA_SIZE <= (2 << 15));
init();
}
..
snip (you can see similar code at
https://github.com/mysql/mysql-server/blob/d0b6dddb74b8f2b042a69c92eced3561176a809d/storage/innobase/include/dyn0buf.h#L54)
```
where:
```
#define UT_LIST_NODE_T(t) ut_list_node
#define UT_LIST_BASE_NODE_T(t, m) \
ut_list_base>
```
(more at
https://github.com/mysql/mysql-server/blob/d0b6dddb74b8f2b042a69c92eced3561176a809d/storage/innobase/include/ut0lst.h#L63
https://github.com/mysql/mysql-server/blob/d0b6dddb74b8f2b042a69c92eced3561176a809d/storage/innobase/include/ut0lst.h#L252
)
The fix seems to be to move the `typedef UT_LIST_BASE_NODE_T(block_t, m_node)
block_list_t;` below the `class block_t {...};` definition.
I have no idea what makes this Windows-specific.
Let me also take this occasion, to share my frustration on the very scarce info
you provide on how to actually run C-Reduce on Windows at
https://llvm.org/docs/HowToSubmitABug.html#frontend-crash (it took me two days
to figure out how to make it work:
https://github.com/zjturner/creduce-windows/issues/2)
--
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 51539] New: [X86] Possibly incorrect throughput for vpshufb/vpperm on bdver2 model
https://bugs.llvm.org/show_bug.cgi?id=51539 Bug ID: 51539 Summary: [X86] Possibly incorrect throughput for vpshufb/vpperm on bdver2 model Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: llvm-...@redking.me.uk CC: craig.top...@gmail.com, lebedev...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, pengfei.w...@intel.com, spatel+l...@rotateright.com I noticed this while working on the D103695 cost model helper script, the llvm-mca reported bdver2 throughput for codegen containing vpshufb/vpperm is often higher than expected. Instruction Info: [1]: #uOps [2]: Latency [3]: RThroughput [4]: MayLoad [5]: MayStore [6]: HasSideEffects (U) [1][2][3][4][5][6]Instructions: 1 3 1.50vpshufb %xmm0, %xmm1, %xmm2 1 2 1.50vpperm%xmm0, %xmm1, %xmm2, %xmm3 https://llvm.godbolt.org/z/Tsc5P4zox All the docs I can find (AMDFam15h SoG, Agner, instlatx64 etc) indicate these are fastpath (tp = 1.0) but just on pipe1 (xbr): https://www.amd.com/system/files/TechDocs/47414_15h_sw_opt_guide.pdf -- 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 51540] New: Performance regression saw after https://reviews.llvm.org/D107998
https://bugs.llvm.org/show_bug.cgi?id=51540 Bug ID: 51540 Summary: Performance regression saw after https://reviews.llvm.org/D107998 Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Scalar Optimizations Assignee: unassignedb...@nondot.org Reporter: w...@google.com CC: llvm-bugs@lists.llvm.org Created attachment 25169 --> https://bugs.llvm.org/attachment.cgi?id=25169&action=edit testcase 1.cc We have seen ~10% performance regression on two of our internal microbenchmark on x86-64. Here is a small testcase to reproduce it. clang-with-D107998 -O3 -fexperimental-new-pass-manager -std=c++17 -fsized-deallocation -msse4.2 -fno-omit-frame-pointer -S 1.cc -o 1.s clang-without-D107998 -O3 -fexperimental-new-pass-manager -std=c++17 -fsized-deallocation -msse4.2 -fno-omit-frame-pointer -S 1.cc -o 2.s Look at the first block in the loop in function _Z1rv. 1.s has 20 instructions while 2.s has 16 instructions. 1.s .LBB1_1:# =>This Inner Loop Header: Depth=1 movq %r15, %rbx shrq $2, %rbx movq %r15, %rcx #APP andl $3, %ecx #NO_APP setne %dl leaq 1(%rcx), %rsi movswq f(%r15,%r15), %rax movzbl (%r14,%rbx), %r15d addq $2, %rbx movzbl (%r14,%rcx), %edi testb %dl, %dl cmovneq %rdi, %r15 testb %dl, %dl cmovneq %rsi, %rbx #APP #NO_APP movzbl %al, %r12d movl f(,%rcx,4), %ecx andl q(%rip), %ecx movq %rax, %r13 subq %rcx, %r13 jg .LBB1_2 2.s .LBB1_1:# =>This Inner Loop Header: Depth=1 movswq f(%r14,%r14), %rax movq %r14, %rcx shrq $2, %rcx #APP andl $3, %r14d #NO_APP movzbl (%r15,%rcx), %ebx movzbl (%r15,%r14), %edx cmovneq %rdx, %rbx leaq 1(%r15,%r14), %rsi leaq 2(%r15,%rcx), %r15 cmovneq %rsi, %r15 #APP #NO_APP movzbl %al, %r12d movl f(,%r14,4), %ecx andl q(%rip), %ecx movq %rax, %r14 subq %rcx, %r14 jg .LBB1_2 -- 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 51541] New: [Analyzer][solver] Reachable infeasible state
https://bugs.llvm.org/show_bug.cgi?id=51541
Bug ID: 51541
Summary: [Analyzer][solver] Reachable infeasible state
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: martongab...@gmail.com
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 25172
--> https://bugs.llvm.org/attachment.cgi?id=25172&action=edit
lit test file
We reach an infeasible state in the below case. I'm attaching also the lit test
file (solver-x.c) that fails/crashes. My guess is that the solver probably
handles `-=` wrongly.
```
int a, b, c, d, e;
void f() {
if (a == 0)
return;
if (e != c)
return;
d = e - c;
b = d;
a -= d;
if (a != 0)
return;
clang_analyzer_warnIfReached(); // no-warning
// Crashes with expensive checks.
if (b > 0)
return;
}
```
--
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 36836 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in clang::APValue::operator=
Updates: Status: WontFix Comment #1 on issue 36836 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in clang::APValue::operator= https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=36836#c1 ClusterFuzz testcase 5487052966723584 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 50985] mov + mul + dup instructions are used for memset instead of just dup
https://bugs.llvm.org/show_bug.cgi?id=50985 Owen Anderson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Owen Anderson --- Fixed in 06a4c858901d72389e01fbdd0f83b03c74d56831 -- 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 51542] New: Clang on Windows: under FE_UPWARD printf(“%.1f\n”, 0.0) prints 0.1 instead of 0.0
https://bugs.llvm.org/show_bug.cgi?id=51542
Bug ID: 51542
Summary: Clang on Windows: under FE_UPWARD printf(“%.1f\n”,
0.0) prints 0.1 instead of 0.0
Product: clang
Version: 12.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C
Assignee: unassignedclangb...@nondot.org
Reporter: pavel.moroz...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Sample code (t928.c):
#include
#include
#pragma fenv_access (on)
int main(void)
{
int i = fesetround( FE_UPWARD );
if ( ! i )
{
printf( "%.1f\n", 0.0 );
}
return 0;
}
Invocation: clang t928.c -Wall -Wextra -std=c11 -ffp-model=strict -pedantic &&
./a.exe
Expected output: 0.0
Actual output: 0.1
Tool version: 12.0.0
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51543] New: Mapping is broken when object part is mapped together with unrelated parts
https://bugs.llvm.org/show_bug.cgi?id=51543 Bug ID: 51543 Summary: Mapping is broken when object part is mapped together with unrelated parts Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Runtime Library Assignee: unassignedb...@nondot.org Reporter: jdoerf...@anl.gov CC: a.bat...@hotmail.com, george_ro...@hotmail.com, jdenny.o...@gmail.com, llvm-bugs@lists.llvm.org, pro...@itc.rwth-aachen.de Created attachment 25173 --> https://bugs.llvm.org/attachment.cgi?id=25173&action=edit reproducer I was playing around with an example and I fail to understand the behavior, consequently I suspect a bug. The test.cpp file attached shows 3 target regions. All execute 1 loop iteration and write a value into an array of size 1. Only, the middle one uses a member of the previously mapped object. While that should not influence the array of size 1, IMHO, it seems to do for some reason. I see Broken: 0x0 but I would expect Broken: 0x7. -- 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 51535] why gotpcrel is generated after llvm 12?
https://bugs.llvm.org/show_bug.cgi?id=51535 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@maskray.me Resolution|--- |INVALID --- Comment #3 from Fangrui Song --- In principle the compiler can use GOT in -fno-pic mode. It is even desired to do so for undefined symbols. For defined symbols, omitting GOT whenever possible is fine. @arr = common dso_local global [8 x i8] zeroinitializer => movabsq $arr, %rdi @arr = common dso_preemptable global [8 x i8] zeroinitializer => movqarr@GOTPCREL(%rip), %rdi Clang correctly sets dso_local/dso_preemptable. If your frontend wants to use absolute relocations, please set dso_local explicitly. -- 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 51544] New: [concepts] Can template / constraint functions be inherited?
https://bugs.llvm.org/show_bug.cgi?id=51544
Bug ID: 51544
Summary: [concepts] Can template / constraint functions be
inherited?
Product: clang
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: l...@marehr.dialup.fu-berlin.de
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
Hi clang-team,
I'm not sure if this is a defect or standard behaviour, but the following code
compiles with gcc, but not with clang:
```cpp
#include
#ifndef MODE
#define MODE 0
#endif
struct base {
#if MODE == 0
void foo(float target){};
#elif MODE == 1
template
void foo(target_t target){};
#elif MODE == 2
template
void foo(target_t target){};
#endif
};
struct bar : public base {
using base::foo;
template
void foo(target_t target){};
};
int main() {
bar f{};
f.foo(float{});
}
```
https://godbolt.org/z/GGjbqdbvq
MODE | 0 | 1 | 2 |
--|---|---|---|
gcc | ✓ | ✓ | ✓ |
clang | ✓ | ✗ | ✗ |
msvc | ✓ | ✗ | ✗ |
I'm unsure if constructs like this are even allowed.
Thank you!
--
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 51545] New: Static Local of Inlined Func in Orphaned DWARF DIE
https://bugs.llvm.org/show_bug.cgi?id=51545
Bug ID: 51545
Summary: Static Local of Inlined Func in Orphaned DWARF DIE
Product: libraries
Version: 12.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: ellis.sparky.h...@gmail.com
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
https://bugs.llvm.org/show_bug.cgi shows the same bug but the info seems to be
outdated.
Function-local static variable do not have the correct debug info when their
function is inlined and removed. The root cause is that DIEs for globals are
created before the abstract origin DIEs from inlined subroutines are created.
In this example, the local variable is a child of `foo`'s correct DIE, but the
static global DIE is a child of an orphaned DIE. That orphaned DIE was expected
to be filled in when `foo` is emitted, but that doesn't happen in this example.
```
void mark_used(int *);
__attribute__((always_inline))
static void foo() {
static int global = 0;
int local = 0;
mark_used(&global);
mark_used(&local);
}
int main() {
foo();
return 0;
}
```
```
$ clang -g main.cpp -c -o - | llvm-dwarfdump -
0x000b: DW_TAG_compile_unit
DW_AT_producer("Apple clang version 12.0.5
(clang-1205.0.22.9)")
DW_AT_language(DW_LANG_C_plus_plus)
DW_AT_name("main.cpp")
DW_AT_APPLE_sdk ("MacOSX.sdk")
DW_AT_stmt_list (0x)
DW_AT_low_pc (0x)
DW_AT_high_pc (0x0033)
0x0032: DW_TAG_subprogram
0x0033: DW_TAG_variable
DW_AT_name("global")
DW_AT_type(0x0049 "int")
DW_AT_decl_file ("main.cpp")
DW_AT_decl_line (4)
DW_AT_location(DW_OP_addr 0x408)
0x0048: NULL
0x0049: DW_TAG_base_type
DW_AT_name ("int")
DW_AT_encoding (DW_ATE_signed)
DW_AT_byte_size (0x04)
0x0050: DW_TAG_subprogram
DW_AT_linkage_name ("_ZL3foov")
DW_AT_name ("foo")
DW_AT_decl_file ("main.cpp")
DW_AT_decl_line (3)
DW_AT_inline(DW_INL_inlined)
0x005c: DW_TAG_variable
DW_AT_name("local")
DW_AT_decl_file ("main.cpp")
DW_AT_decl_line (5)
DW_AT_type(0x0049 "int")
0x0067: NULL
0x0068: DW_TAG_subprogram
DW_AT_low_pc(0x)
DW_AT_high_pc (0x0033)
DW_AT_frame_base(DW_OP_reg6 RBP)
DW_AT_name ("main")
DW_AT_decl_file ("main.cpp")
DW_AT_decl_line (10)
DW_AT_type (0x0049 "int")
DW_AT_external (true)
0x0081: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x0050 "_ZL3foov")
DW_AT_low_pc (0x000f)
DW_AT_high_pc (0x002d)
DW_AT_call_file ("main.cpp")
DW_AT_call_line (11)
DW_AT_call_column (0x03)
0x0095: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -4)
DW_AT_abstract_origin (0x005c "local")
0x009d: NULL
0x009e: NULL
0x009f: NULL
```
You'll also notice that only the local variable is a child of the inlined
subroutine for `foo` and the static variable is missing.
I made a test case below, but I haven't figured out a good solution without
breaking other test cases.
```
; RUN: %llc_dwarf -O0 -filetype=obj < %s | llvm-dwarfdump -v -debug-info - |
FileCheck --implicit-check-not "{{DW_TAG|NULL}}" %s
; CHECK: DW_TAG_compile_unit
; CHECK: DW_TAG_subprogram
; CHECK: DW_AT_name {{.*}} "foo"
; CHECK: DW_TAG_variable
; CHECK: DW_AT_name {{.*}} "static_var"
; CHECK: DW_TAG_variable
; CHECK: DW_AT_name {{.*}} "local_var"
; CHECK: NULL
; CHECK: DW_TAG_base_type
; CHECK: DW_TAG_subprogram
; CHECK: DW_AT_name {{.*}} "main"
; CHECK: DW_TAG_inlined_subroutine
; CHECK: DW_AT_abstract_origin {{.*}} "foo"
; CHECK; DW_TAG_variable
; CHECK; DW_AT_abstract_origin {{.*}} "static_var"
; CHECK: DW_TAG_variable
; CHECK: DW_AT_abstract_origin {{.*}} "local_var"
; CHECK: NULL
; CHECK: NULL
; CHECK: NULL
@static_var = internal global i32 4, align 4, !dbg !0
define i32 @main() !dbg !7 {
store i32 0, i32* @stat
[llvm-bugs] [Bug 51543] Mapping is broken when object part is mapped together with unrelated parts
https://bugs.llvm.org/show_bug.cgi?id=51543 Johannes Doerfert changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Johannes Doerfert --- n_ was not initialized. My bad. Thanks Joachim! -- 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 51546] New: ICE on compilable code: llvm::TargetLoweringBase::getRegClassFor(llvm::MVT, bool) const: Assertion `RC && "This value type is not natively supported!"' failed.
https://bugs.llvm.org/show_bug.cgi?id=51546
Bug ID: 51546
Summary: ICE on compilable code:
llvm::TargetLoweringBase::getRegClassFor(llvm::MVT,
bool) const: Assertion `RC && "This value type is not
natively supported!"' failed.
Product: clang
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: -New Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: cn...@uwaterloo.ca
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org,
neeil...@live.com, richard-l...@metafoo.co.uk
$ clang-trunk -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
f5d5f17d3ad455de2fbb9448acea66cbc09561c5)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/cnsun/usr/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/9
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$ cat mutant.c
__attribute__((target("general-regs-only"))) foo1() {
union {
long double d;
} e;
a(e.d);
}
$ clang-trunk mutant.c
mutant.c:1:46: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
__attribute__((target("general-regs-only"))) foo1() {
^
mutant.c:5:3: warning: implicit declaration of function 'a' is invalid in C99
[-Wimplicit-function-declaration]
a(e.d);
^
mutant.c:6:1: warning: non-void function does not return a value
[-Wreturn-type]
}
^
clang-14:
/tmp/tmp.juz6ZsGfL6-clang-builder/llvm-project/llvm/include/llvm/CodeGen/TargetLowering.h:855:
virtual const llvm::TargetRegisterClass*
llvm::TargetLoweringBase::getRegClassFor(llvm::MVT, bool) const: Assertion `RC
&& "This value type is not natively supported!"' failed.
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: /scratch/software/clang-trunk/bin/clang-14 -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations
-disable-free -main-file-name mutant.c -mrelocation-model static
-mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb
-fcoverage-compilation-dir=/scratch/cnsun/workspace/perses-fuzzer/temp_testing_campaigns/default_finding_folder_c/crash_20210819_073934_02e6/delta/perses_result
-resource-dir /scratch/software/clang-trunk/lib/clang/14.0.0 -c-isystem .
-c-isystem /usr/local/include/cmsith -internal-isystem
/scratch/software/clang-trunk/lib/clang/14.0.0/include -internal-isystem
/usr/local/include -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../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=/scratch/cnsun/workspace/perses-fuzzer/temp_testing_campaigns/default_finding_folder_c/crash_20210819_073934_02e6/delta/perses_result
-ferror-limit 19 -fgnuc-version=4.2.1 -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1
-o /tmp/mutant-c04690.o -x c mutant.c
1. parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'mutant.c'.
4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo1'
#0 0x556194a9f9a4 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x556194a9d0be SignalHandler(int) Signals.cpp:0:0
#2 0x7fcce9f843c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#3 0x7fcce9a2318b raise
/build/glibc-ZN95T4/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#4 0x7fcce9a02859 abort /build/glibc-ZN95T4/glibc-2.31/stdlib/abort.c:81:7
#5 0x7fcce9a02729 get_sysdep_segment_value
/build/glibc-ZN95T4/glibc-2.31/intl/loadmsgcat.c:509:8
#6 0x7fcce9a02729 _nl_load_domain
/build/glibc-ZN95T4/glibc-2.31/intl/loadmsgcat.c:970:34
#7 0x7fcce9a13f36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
#8 0x556195a189ee llvm::FunctionLoweringInfo::CreateRegs(llvm::Type*,
bool) (/scratch/software/clang-trunk/bin/clang-14+0x4b249ee)
#9 0x556195a0adaf
llvm::FunctionLoweringInfo::InitializeRegForValue(llvm::Value const*)
(/scratch/software/clang-trunk/bin/clang-14+0x4b16daf)
#10 0x556195a763f9 llvm::SelectionDAGBuilder::getValueImpl(llvm::Value
const*) (/scratch/software/clang-trunk/bin/clang-14+0x4b823f9)
#11 0x556195a7c0f5 llvm::SelectionDAGBuilder::getValue(llvm::Value const*)
(/scratch/software/clang-trunk/bin/clang-14+0x4b880f5)
#12 0x556195a89475 llvm::SelectionDAGBuilde
[llvm-bugs] [Bug 51547] New: ICE attempting to deduce array of class template in new-expression
https://bugs.llvm.org/show_bug.cgi?id=51547
Bug ID: 51547
Summary: ICE attempting to deduce array of class template in
new-expression
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++17
Assignee: unassignedclangb...@nondot.org
Reporter: e...@catmur.co.uk
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk
template struct A;
auto p = new A[]{};
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
41e3ac398c3ae9dfba5a57d80c420c122c1ec700)
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/clang++ -g -o
/app/output.s -S --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot
-fcolor-diagnostics -fno-crash-diagnostics -std=c++17
1. :2:19: current parser token ';'
#0 0x55bcd3c5a36f PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
#1 0x55bcd3c58230 llvm::sys::CleanupOnSignal(unsigned long)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x34fe230)
#2 0x55bcd3ba9218 CrashRecoverySignalHandler(int)
CrashRecoveryContext.cpp:0:0
#3 0x7fa8a9f953c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#4 0x55bcd6602d65 clang::Expr::getExprLoc() const
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5ea8d65)
#5 0x55bcd5e89bdd clang::Sema::BuildCXXNew(clang::SourceRange, bool,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation, clang::SourceRange, clang::QualType,
clang::TypeSourceInfo*, llvm::Optional, clang::SourceRange,
clang::Expr*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x572fbdd)
#6 0x55bcd5e8b006 clang::Sema::ActOnCXXNew(clang::SourceLocation, bool,
clang::SourceLocation, llvm::MutableArrayRef,
clang::SourceLocation, clang::SourceRange, clang::Declarator&, clang::Expr*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5731006)
#7 0x55bcd5a6d9e0 clang::Parser::ParseCXXNewExpression(bool,
clang::SourceLocation)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x53139e0)
#8 0x55bcd5a5e486
clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool, bool&,
clang::Parser::TypeCastState, bool, bool*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5304486)
#9 0x55bcd5a60c26
clang::Parser::ParseCastExpression(clang::Parser::CastParseKind, bool,
clang::Parser::TypeCastState, bool, bool*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5306c26)
#10 0x55bcd5a60cb8
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x5306cb8)
#11 0x55bcd5a2cc20
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x52d2c20)
#12 0x55bcd5a3db15 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*, clang::Parser::ForRangeInit*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x52e3b15)
#13 0x55bcd5a0faf9
clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x52b5af9)
#14 0x55bcd5a10201
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) (.part.280) Parser.cpp:0:0
#15 0x55bcd5a16129
clang::Parser::ParseExternalDeclaration(clang::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x52bc129)
#16 0x55bcd5a17549
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr&, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x52bd549)
#17 0x55bcd5a0ada9 clang::ParseAST(clang::Sema&, bool, bool)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x52b0da9)
#18 0x55bcd4bb1c12 clang::CodeGenAction::ExecuteAction()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x4457c12)
#19 0x55bcd455d381 clang::FrontendAction::Execute()
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3e03381)
#20 0x55bcd44fb3e2
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3da13e2)
#21 0x55bcd4629713
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(/opt/compiler-explorer/clang-trunk/bin/clang+++0x3ecf713)
#22 0x55bcd19e410c cc1_main(llvm::ArrayRef, char const*,
void*) (/opt/compiler-explorer/clang-trunk/bin/clang+++0x128a10c)
#23 0x55bcd19e02dd ExecuteCC1Tool(llvm::SmallVectorImpl&)
driver.cpp:0:0
#24 0x55bcd43a61a5 void llvm::function_ref::callback_fn
>, std::__cxx11::basic_string,
std::allocator >*, bool*) const::'lambda'()>(long) Job.cpp:0:0
#25 0x55bcd3ba9803
llvm::CrashRecoveryContext::RunSafely(llvm::func
[llvm-bugs] [Bug 51020] Assertion `AL->size() == ActualAccesses.size() && "We don't have the same number of accesses in the block as on the " "access list"' failed.
https://bugs.llvm.org/show_bug.cgi?id=51020 Alina Sbirlea changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #10 from Alina Sbirlea --- Bug status updated. Thank you for sending out the patches! -- 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 51545] Static Local of Inlined Func in Orphaned DWARF DIE
https://bugs.llvm.org/show_bug.cgi?id=51545 Ellis Hoag changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Ellis Hoag --- *** This bug has been marked as a duplicate of bug 30637 *** -- 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 51517] "CUDA error: device kernel image is invalid" with ELF standard notes
https://bugs.llvm.org/show_bug.cgi?id=51517 Michael Kruse changed: What|Removed |Added Fixed By Commit(s)||1ffbe8c04ff269ca9847c37036f ||bad943820d6ae Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Michael Kruse --- Closing as fixed. Buildbots agree. http://meinersbur.de:8011/#/builders/1/builds/542 http://meinersbur.de:8011/#/builders/117/builds/405 -- 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 50436] Codegen for shuffle (similar to vget_low_s8) can be improved
https://bugs.llvm.org/show_bug.cgi?id=50436 Thomas Lively changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||b69374ca58d3 Status|NEW |RESOLVED --- Comment #1 from Thomas Lively --- This is fixed by https://reviews.llvm.org/rGb69374ca58d3e5e62688efd8149417499096d8a7 -- 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 51548] New: [libc++][PowerPC] align.pass.cpp test failure for 13.0.0-rc1 on PowerPC
https://bugs.llvm.org/show_bug.cgi?id=51548 Bug ID: 51548 Summary: [libc++][PowerPC] align.pass.cpp test failure for 13.0.0-rc1 on PowerPC Product: new-bugs Version: trunk Hardware: PC OS: Linux Status: NEW Severity: release blocker Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: amyk@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 51236 The following libc++ LIT test fails on 13.0.0-rc1 for Ubuntu on Power: libc++ :: libcxx/atomics/atomics.align/align.pass.cpp - An assertion of the following is produced for this test: # command stderr: t.tmp.exe: /home/conanap/llvm/community/llvm-project/libcxx/test/libcxx/atomics/atomics.align/align.pass.cpp:41: atomic_test::atomic_test() [T = LLIArr2]: Assertion `alignof(AtomicImpl) >= sizeof(AtomicImpl) && "expected natural alignment for lock-free type"' failed. error: command failed with exit status: 250 This failure is still being investigated. 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 51549] New: considering conversion functions in the context of copy-initializing a type from the same type
https://bugs.llvm.org/show_bug.cgi?id=51549
Bug ID: 51549
Summary: considering conversion functions in the context of
copy-initializing a type from the same type
Product: clang
Version: 11.0
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: barry.rev...@gmail.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Reduced from StackOverflow (https://stackoverflow.com/q/68853472/2069064):
template
concept Numeric =
requires(T a) {
foo(a);
};
struct Deferred {
friend void foo(Deferred);
template operator TO();
};
static_assert(Numeric);
clang is trying to check to see if a.operator Derived() is a valid expression
as part of checking if foo(a) is valid. But we shouldn't be going that route
here at all, copy-initializing a Derived from an lvalue of type Derived should
only check constructors, not conversion functions.
--
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 51550] New: LoopIdiom does not produce memcpy/memset with runtime checks if pointers may alias
https://bugs.llvm.org/show_bug.cgi?id=51550
Bug ID: 51550
Summary: LoopIdiom does not produce memcpy/memset with runtime
checks if pointers may alias
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
typedef __SIZE_TYPE__ size_t;
void idiom_memcpy_aliasing(unsigned char * dst, size_t d_len, unsigned char
*src)
{
// no restrict, possible aliasing
unsigned char *d_end = dst + d_len;
// icc seems to produce memcpy when alias checks are OK and d_len j < 96,
jumps to trivial copy loop otherwise.
while (dst < d_end)
*dst++ = *src++;
}
ICC -O2+ is able to do this kind of transformation.
https://godbolt.org/z/eK1P4YjMf
--
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 51551] New: Missed optimization for (X * odd number) & 1
https://bugs.llvm.org/show_bug.cgi?id=51551
Bug ID: 51551
Summary: Missed optimization for (X * odd number) & 1
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
define i1 @src(i32 %0, i32 %1) {
%2:
%3 = and i32 %1, 1
%4 = icmp ne i32 %3, 0
assume i1 %4
%5 = mul i32 %1, %0
%6 = and i32 %5, 1
%7 = icmp eq i32 %6, 0
ret i1 %7
}
=>
define i1 @tgt(i32 %0, i32 %1) {
%2:
%3 = and i32 %0, 1
%4 = icmp eq i32 %3, 0
ret i1 %4
}
Transformation seems to be correct!
https://godbolt.org/z/eee8ETo4h
--
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 51098] WebAssembly doesn't always generate f64x2.convert_low_i32x4_s/u as expected
https://bugs.llvm.org/show_bug.cgi?id=51098 Thomas Lively changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Fixed By Commit(s)||b311a040ef9cda6d52fdfdd4968 ||f2dc59ccf596e --- Comment #6 from Thomas Lively --- Fixed in https://reviews.llvm.org/rGb311a040ef9cda6d52fdfdd4968f2dc59ccf596e with follow-on optimizations in https://reviews.llvm.org/rGfd0557dbf13198ddd6a17bd120a7b2bb97bfbd0a -- 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 51552] New: -O0 built openmp offload for nvidia, occasionally fails trying to copy data
https://bugs.llvm.org/show_bug.cgi?id=51552
Bug ID: 51552
Summary: -O0 built openmp offload for nvidia, occasionally
fails trying to copy data
Product: OpenMP
Version: unspecified
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Runtime Library
Assignee: unassignedb...@nondot.org
Reporter: rlieb...@amd.com
CC: llvm-bugs@lists.llvm.org
cmake command to build trunk for nvptx
cmake -DCMAKE_INSTALL_PREFIX=/xtmp/rlieberm/trunkNvptx_1.0 \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_PROJECTS="clang" \
-DLLVM_TARGETS_TO_BUILD="X86;NVPTX" \
-DLLVM_ENABLE_ASSERTIONS=ON\
-DLLVM_CCACHE_BUILD=$OPTION_CCACHE \
-DLLVM_ENABLE_RUNTIMES="openmp" \
-DLIBOMPTARGET_CMAKE_BUILD_TYPE=debug \
../llvm
compile command
/xtmp/rlieberm/trunkNvptx_1.0//bin/clang -O0 -target x86_64-pc-linux-gnu
-fopenmp -fopenmp-targets=nvptx64-nvidia-cuda
-Xopenmp-target=nvptx64-nvidia-cuda -march=sm_50 nested_loop.c -o nested_loop
-L/usr/local/cuda/targets/x86_64-linux/lib -lcudart
execution, this is intermittent in failure, so it may reproduce , i hope so
$ LIBOMPTARGET_INFO=16 LD_LIBRARY_PATH=/xtmp/rlieberm/trunkNvptx_1.0/lib
./nested_loop
CUDA device 0 info: Device supports up to 65536 CUDA blocks and 1024 threads
with a warp size of 32
CUDA device 0 info: Device heap size is 8388608 Bytes, device stack size is
1024 Bytes per thread
CUDA device 0 info: Launching kernel __omp_offloading_811_181cfa_main_l9 with 1
blocks and 38 threads in Generic mode
CUDA error: an illegal memory access was encountered
Libomptarget error: Copying data from device failed.
Libomptarget error: Call to targetDataEnd failed, abort target.
Libomptarget error: Failed to process data after launching the kernel.
Libomptarget error: Run with LIBOMPTARGET_INFO=4 to dump host-target pointer
mappings.
Libomptarget error: Source location information not present. Compile with -g or
-gline-tables-only.
Libomptarget fatal error 1: failure of target construct while offloading is
mandatory
Aborted (core dumped)
Test case:
#include
#include "assert.h"
#include
int t1 = 6;
int main() {
int wayout=0;
#pragma omp target map(tofrom: wayout)
#pragma omp teams num_teams(1 ) thread_limit(t1)
{ wayout =1;
}
printf("wayout=%d\n", wayout);
if(wayout==1){
printf("Succeeded\n");
return 0;
} else {
printf("Failed\n");
return 1;
}
}
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 51553] New: Crash on -O3: typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X = llvm::Instruction; Y = llvm::Value; typename llvm::cast_retty::ret_type = llvm::In
https://bugs.llvm.org/show_bug.cgi?id=51553
Bug ID: 51553
Summary: Crash on -O3: typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X =
llvm::Instruction; Y = llvm::Value; typename
llvm::cast_retty::ret_type =
llvm::Instruction*]: Assertion `isa(Val) &&
"cast() argument of incompatible type!"'
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: haoxi...@gmail.com
CC: llvm-bugs@lists.llvm.org
Hi all.
This valid code makes the trunk clang crash at -O3.
$cat small.c
#include
int a;
volatile uint64_t b;
c() {
int16_t *d = a;
for (;;) {
uint8_t e;
volatile int f = ((*d = 40780) / (e = f) ? 0 : b) >> 4;
}
}
$clang -w -O3 small.c
clang-14:
/home/haoxin/haoxin-data/compilers/llvm-project/llvm/include/llvm/Support/Casting.h:269:
typename llvm::cast_retty::ret_type llvm::cast(Y*) [with X =
llvm::Instruction; Y = llvm::Value; typename llvm::cast_retty::ret_type
= llvm::Instruction*]: Assertion `isa(Val) && "cast() argument of
incompatible type!"' failed.
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:
/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj --mrelax-relocations -disable-free
-main-file-name small.c -mrelocation-model static -mframe-pointer=none
-fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb
-fcoverage-compilation-dir=/home/haoxin/haoxin-data/dut-research/covsmith-test/20210819/reduce
-resource-dir
/home/haoxin/haoxin-data/compilers/llvm-project/build/lib/clang/14.0.0
-internal-isystem
/home/haoxin/haoxin-data/compilers/llvm-project/build/lib/clang/14.0.0/include
-internal-isystem /usr/local/include -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O3
-w
-fdebug-compilation-dir=/home/haoxin/haoxin-data/dut-research/covsmith-test/20210819/reduce
-ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops
-vectorize-slp -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/small-38757f.o
-x c small.c
1. parser at end of file
2. Optimizer
#0 0x55f61ea17514 PrintStackTraceSignalHandler(void*)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x3b17514)
#1 0x55f61ea14c2e SignalHandler(int)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x3b14c2e)
#2 0x7fd8c4e3e3c0 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
#3 0x7fd8c48dd18b raise
/build/glibc-eX1tMB/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#4 0x7fd8c48bc859 abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:81:7
#5 0x7fd8c48bc729 get_sysdep_segment_value
/build/glibc-eX1tMB/glibc-2.31/intl/loadmsgcat.c:509:8
#6 0x7fd8c48bc729 _nl_load_domain
/build/glibc-eX1tMB/glibc-2.31/intl/loadmsgcat.c:970:34
#7 0x7fd8c48cdf36 (/lib/x86_64-linux-gnu/libc.so.6+0x36f36)
#8 0x55f61e34c021 llvm::TruncInstCombine::ReduceExpressionDag(llvm::Type*)
(.localalias)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x344c021)
#9 0x55f61e34f2c7 llvm::TruncInstCombine::run(llvm::Function&)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x344f2c7)
#10 0x55f61e34935a runImpl(llvm::Function&, llvm::TargetLibraryInfo&,
llvm::DominatorTree&)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x344935a)
#11 0x55f61e34a2fb llvm::AggressiveInstCombinePass::run(llvm::Function&,
llvm::AnalysisManager&)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x344a2fb)
#12 0x55f61fc27e56 llvm::detail::PassModel >::run(llvm::Function&,
llvm::AnalysisManager&)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x4d27e56)
#13 0x55f61e10cf36 llvm::PassManager >::run(llvm::Function&,
llvm::AnalysisManager&)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x320cf36)
#14 0x55f61c50ecf6 llvm::detail::PassModel >,
llvm::PreservedAnalyses, llvm::AnalysisManager
>::run(llvm::Function&, llvm::AnalysisManager&)
(/home/haoxin/haoxin-data/compilers/llvm-project/build/bin/clang-14+0x160ecf6)
#15 0x55f61d7c6f1f
llvm::CGSCCToFunctionPassAdaptor::run(llvm::LazyCallGraph::SCC&,
llvm::AnalysisManager&,
llvm::Lazy
[llvm-bugs] [Bug 14641] Unknown mismatch! UNREACHABLE executed at lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:212!
https://bugs.llvm.org/show_bug.cgi?id=14641 Yaron Keren changed: What|Removed |Added CC||yaron.ke...@gmail.com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Yaron Keren --- does not reproduce anymore: $ bin/clang -c f.c f.c:6:5: error: invalid output constraint '=f' in asm : "=f" (x) ^ 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] [Bug 51128] clang-cl --target=arm64-pc-windows-msvc doesn't support __umulh needed by WinSDK 10.0.20348.0
https://bugs.llvm.org/show_bug.cgi?id=51128 Tom Stellard changed: What|Removed |Added Fixed By Commit(s)|cc3affd8b02091bf475f9dd0838 |cc3affd8b02091bf475f9dd0838 |02e1b6a232be1 |02e1b6a232be1 ddc49d0f1f2b Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Tom Stellard --- Merged: ddc49d0f1f2b -- 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 51128, which changed state. Bug 51128 Summary: clang-cl --target=arm64-pc-windows-msvc doesn't support __umulh needed by WinSDK 10.0.20348.0 https://bugs.llvm.org/show_bug.cgi?id=51128 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 51346] Clang changed -ffp-contract flag to "on", breaking serval client as well as SPEC2006 and SPEC2017 tests.
https://bugs.llvm.org/show_bug.cgi?id=51346 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)|4389a413e2129d7d55ee779638b |4389a413e2129d7d55ee779638b |649aa852b6f8a |649aa852b6f8a 34f839fc9d4c --- Comment #41 from Tom Stellard --- Merged: 34f839fc9d4c -- 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 46079] Failure to use vfmadd132sd when appropriate
https://bugs.llvm.org/show_bug.cgi?id=46079 Bug 46079 depends on bug 51346, which changed state. Bug 51346 Summary: Clang changed -ffp-contract flag to "on", breaking serval client as well as SPEC2006 and SPEC2017 tests. https://bugs.llvm.org/show_bug.cgi?id=51346 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 51346, which changed state. Bug 51346 Summary: Clang changed -ffp-contract flag to "on", breaking serval client as well as SPEC2006 and SPEC2017 tests. https://bugs.llvm.org/show_bug.cgi?id=51346 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 51533] [lldb] Merge 5033f0793fe6 and cf521e78dfd2 into 13.0.0
https://bugs.llvm.org/show_bug.cgi?id=51533 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|5033f0793fe6 cf521e78dfd2 |5033f0793fe6 cf521e78dfd2 ||535b7fb2201a 10a4a861837d Status|NEW |RESOLVED --- Comment #1 from Tom Stellard --- Merged: 10a4a861837d -- 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 51533, which changed state. Bug 51533 Summary: [lldb] Merge 5033f0793fe6 and cf521e78dfd2 into 13.0.0 https://bugs.llvm.org/show_bug.cgi?id=51533 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 51554] New: [clang][ParseEnum] Crashed: Enum with invalid use of incomplete type
https://bugs.llvm.org/show_bug.cgi?id=51554
Bug ID: 51554
Summary: [clang][ParseEnum] Crashed: Enum with invalid use of
incomplete type
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangb...@nondot.org
Reporter: guopeil...@huawei.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
I have a test case where clang should give an error message rather than a
crash.
The test command is `clang++ -O2 test.cpp`
The test case is as follows:
enum E { e = E() };
int main() {
return 0;
}
The error message should be like the following:
test.cpp:1:14: error: invalid use of incomplete type 'E'
enum E { e = E() };
^~~
test.cpp:1:6: note: definition of 'E' is not complete until the closing '}'
enum E { e = E() };
However, the trunk get crashed with the assertion
The bug message:
```
./clang/include/clang/AST/Type.h:677: const clang::ExtQualsTypeCommonBase*
clang::QualType::getCommonPtr() const: Assertion `!isNull() && "Cannot retrieve
a NULL type pointer"' failed.
```
I did a simple analysis.
In ParseDecl.cpp:
1. llvm-10:
AssignedVal.get(): NULL
2. llvm-12(Context.getLangOpts().RecoveryASTType: default
false)(early-version):
AssignedVal.get(): RecoveryExpr 0xba19df20 ''
contains-errors lvalue
3. llvm-12(Context.getLangOpts().RecoveryASTType: default true)
(latest-version, Finally crashed):
AssignedVal.get()->dump(): RecoveryExpr 0xbb4d9500 'enum E'
contains-errors
In CheckEnumConstant(), EltTy(type: QualType, value: EnumType 0xbb517dd0
'enum E') cannot use getIntWidth(), so crashed. But the code doesn't seem to be
wrong around here.
--
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
