[llvm-bugs] [Bug 51555] New: WebAssembly .s format can omit .globaltype for __stack_pointer
https://bugs.llvm.org/show_bug.cgi?id=51555
Bug ID: 51555
Summary: WebAssembly .s format can omit .globaltype for
__stack_pointer
Product: new-bugs
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: kei...@cs.stanford.edu
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Created attachment 25178
--> https://bugs.llvm.org/attachment.cgi?id=25178&action=edit
bug.s
After commit 9647a6f, the WebAssemblyAsmPrinter can omit the .globaltype for
__stack_pointer, leading to a .s file that the assembler rejects.
To reproduce:
```
$ cat > bug.c
void unused_function(void) {}
void function(int x, int y) {}
void dosomething(void)
{
function(0, 0);
}
$ clang -S -o bug.s bug.c && clang -c -o bug.o bug.s
bug.s:23:2: error: symbol __stack_pointer missing .globaltype
global.get __stack_pointer
^
```
--
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 45978] Build error when using MSVC generator
https://bugs.llvm.org/show_bug.cgi?id=45978 Yaron Keren changed: What|Removed |Added Fixed By Commit(s)||rG25c8ffa223ec Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Yaron Keren --- https://reviews.llvm.org/D108444 -- 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 26089] Clang unit test build failure with fatal error C1128: number of sections exceeded
https://bugs.llvm.org/show_bug.cgi?id=26089 Yaron Keren changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||80bd6ae13ea23d453a1f45d6ccd ||bfc7d0c877bb0 CC||yaron.ke...@gmail.com Resolution|--- |FIXED --- Comment #1 from Yaron Keren --- https://github.com/llvm/llvm-project/commit/80bd6ae13ea23d453a1f45d6ccdbfc7d0c877bb0 On Windows build, making the /bigobj flag global , instead of passing… … it per file. To avoid having this flag be passed in per/file manner, we are instead passing it globally. This fixes this bug: https://bugs.llvm.org/show_bug.cgi?id=46733 Reviewed-by: aaron.ballman, beanz, meinersbur Differential Revision: https://reviews.llvm.org/D84038 -- 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 51556] New: Failure to vectorize llvm.isnan calls
https://bugs.llvm.org/show_bug.cgi?id=51556
Bug ID: 51556
Summary: Failure to vectorize llvm.isnan calls
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: enhancement
Priority: P
Component: Scalar Optimizations
Assignee: unassignedb...@nondot.org
Reporter: llvm-...@redking.me.uk
CC: a.bat...@hotmail.com, florian_h...@apple.com,
llvm-bugs@lists.llvm.org, sepavl...@gmail.com,
spatel+l...@rotateright.com
As well as missing Intrinsic::isnan from llvm::isTriviallyVectorizable, the SLP
call vectorization fails as we don't properly account for calls that have
different return/arg types - LV seems to have the same problem but I haven't
looked at that in detail.
opt -mtriple=x86_64-- -mcpu=btver2 -slp-vectorizer
define void @vec_isnan_f64(double* %a, double* %b, double* %c, double* %d) {
; CHECK-LABEL: @vec_isnan_f64(
; CHECK-NEXT: entry:
; CHECK-NEXT:[[AIDX1:%.*]] = getelementptr inbounds double, double*
[[A:%.*]], i64 1
; CHECK-NEXT:[[A0:%.*]] = load double, double* [[A]], align 8
; CHECK-NEXT:[[A1:%.*]] = load double, double* [[AIDX1]], align 8
; CHECK-NEXT:[[TMP0:%.*]] = bitcast double* [[B:%.*]] to <2 x double>*
; CHECK-NEXT:[[TMP1:%.*]] = load <2 x double>, <2 x double>* [[TMP0]],
align 8
; CHECK-NEXT:[[TMP2:%.*]] = bitcast double* [[C:%.*]] to <2 x double>*
; CHECK-NEXT:[[TMP3:%.*]] = load <2 x double>, <2 x double>* [[TMP2]],
align 8
; CHECK-NEXT:[[ISNAN0:%.*]] = tail call i1 @llvm.isnan.f64(double [[A0]])
; CHECK-NEXT:[[ISNAN1:%.*]] = tail call i1 @llvm.isnan.f64(double [[A1]])
; CHECK-NEXT:[[TMP4:%.*]] = insertelement <2 x i1> poison, i1 [[ISNAN0]],
i32 0
; CHECK-NEXT:[[TMP5:%.*]] = insertelement <2 x i1> [[TMP4]], i1 [[ISNAN1]],
i32 1
; CHECK-NEXT:[[TMP6:%.*]] = select <2 x i1> [[TMP5]], <2 x double>
[[TMP1]], <2 x double> [[TMP3]]
; CHECK-NEXT:[[TMP7:%.*]] = bitcast double* [[D:%.*]] to <2 x double>*
; CHECK-NEXT:store <2 x double> [[TMP6]], <2 x double>* [[TMP7]], align 8
; CHECK-NEXT:ret void
;
entry:
%aidx1 = getelementptr inbounds double, double* %a, i64 1
%bidx1 = getelementptr inbounds double, double* %b, i64 1
%cidx1 = getelementptr inbounds double, double* %c, i64 1
%didx1 = getelementptr inbounds double, double* %d, i64 1
%a0 = load double, double* %a, align 8
%b0 = load double, double* %b, align 8
%c0 = load double, double* %c, align 8
%a1 = load double, double* %aidx1, align 8
%b1 = load double, double* %bidx1, align 8
%c1 = load double, double* %cidx1, align 8
%isnan0 = tail call i1 @llvm.isnan.f64(double %a0)
%isnan1 = tail call i1 @llvm.isnan.f64(double %a1)
%r0 = select i1 %isnan0, double %b0, double %c0
%r1 = select i1 %isnan1, double %b1, double %c1
store double %r0, double* %d, align 8
store double %r1, double* %didx1, align 8
ret void
}
declare i1 @llvm.isnan.f64(double)
--
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 51557] New: [SchedModel][MCA] Improve handling of load uOPs and read-advance.
https://bugs.llvm.org/show_bug.cgi?id=51557 Bug ID: 51557 Summary: [SchedModel][MCA] Improve handling of load uOPs and read-advance. Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-mca Assignee: unassignedb...@nondot.org Reporter: andrea.dibia...@gmail.com CC: andrea.dibia...@gmail.com, llvm-bugs@lists.llvm.org, matthew.da...@sony.com Example: ``` vmulps 112(%rsp), %xmm14, %xmm14 vpermilps $85, %xmm14, %xmm14 ``` > llvm-mca -mcpu=skylake -iterations=2 -timeline ``` Timeline view: 0123456789 Index 0123456789 0123 [0,0] DeeER .. . vmulps 112(%rsp), %xmm14, %xmm14 [0,1] D==eER .. . vpermilps $85, %xmm14, %xmm14 [1,0] D==eeER. vmulps 112(%rsp), %xmm14, %xmm14 [1,1] DeER vpermilps $85, %xmm14, %xmm14 ``` However, the expected timeline looks like this: ``` Timeline view: 0123456789 Index 0123456789 0123 [0,0] DeeER .. vmulps 112(%rsp), %xmm14, %xmm14 [0,1] D==eER .. vpermilps $85, %xmm14, %xmm14 [1,0] D=eeER . vmulps 112(%rsp), %xmm14, %xmm14 [1,1] D===eER . vpermilps $85, %xmm14, %xmm14 ``` The reason why mca doesn't schedule the second vmulps in advance, is because the write-back cycle for register XMM14 is unknown until cycle 11. One of the biggest limitations in LLVM, is the inability to independently simulate individual micro-opcodes of an instruction. For a simulator like mca, it means that memory uOPs cannot be accurately tracked. This is the main reason why in general, instructions with memory operands are often poorly simulated. ReadAdvance was originally introduced to workaround the issue related to the inability of processing individual uOPs of an instruction. However, in order to work, read-advance still requires that the write-back cycle for the input register definition is known. In this particular example, the write-back stage for the first VPERMILPS is unknown until cycle 11. Therefore, the write-back of XMM14 is also unknown until then. So, the read-advance in VMULPS can only trigger at that point. That is what prevents the VMULPS from starting earlier. There might be ways to partially work-around this issue in mca. However, I am afraid that a proper solution would require introducing changes to the scheduling model, and how read-advance for memory load operands is defined. Depending on how we decide to address this issue, this bug could potentially have an impact on bug 39829 and bug 39830. -- 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 20368] clang-cl: Assertion failure: "Expected Loc to be at or after Start"
https://bugs.llvm.org/show_bug.cgi?id=20368
Yaron Keren changed:
What|Removed |Added
Resolution|--- |FIXED
CC||yaron.ke...@gmail.com
Status|NEW |RESOLVED
--- Comment #1 from Yaron Keren ---
works with trunk 25c8ffa223ecec8e0c4c3d3772886295bde0c0e9:
$ grep ASSERTIONS CMakeCache.txt
LLVM_ENABLE_ASSERTIONS:BOOL=ON
yaron@YARON:~/build$ cat test3.c
void t36() {
int arr[4];
__asm {
mov eax, 12[4 + arr]
mov eax, 4[64 + arr + (2*32)]
mov eax, 4[64 + arr - 2*32]
mov eax, [arr + 4]
mov eax, [arr + 4 + 32*2 - 4]
mov eax, [4 + arr]
mov eax, [4 + arr + 4]
mov eax, [64 + arr + (2*32)]
mov eax, [64 + arr - 2*32]
}
}
$ bin/clang-cl -c test3.c
$
--
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 51558] New: Address of dllimport symbol is not constexpr
https://bugs.llvm.org/show_bug.cgi?id=51558 Bug ID: 51558 Summary: Address of dllimport symbol is not constexpr Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: skyos...@chromium.org CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk The following C++ program fails to compile on the x64_64-pc-windows-msvc target: extern __declspec(dllimport) int x; constexpr int* y = &x; Error message: test.cc(7,16): error: constexpr variable 'y' must be initialized by a constant expression This is on Clang version 14.0.0 (https://github.com/llvm/llvm-project/ ee65938357d5fffe9e586fa155b37268b5a358ac), target: x86_64-pc-windows-msvc. I ran into this while trying to compile Perfetto (https://perfetto.dev) as a part of Chromium. The same program builds correctly on MSVC (tested on 19.29.30037 for x64). Interestingly, MSVC had a regression related to this in 2018[1] which has since been fixed. [1] https://developercommunity.visualstudio.com/t/c-regression-stdmax-of-two-constexpr-does-not-eval/312456 -- 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 49954] Assertion failed: should not perform lookups into transparent contexts
https://bugs.llvm.org/show_bug.cgi?id=49954 Aaron Ballman changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Aaron Ballman --- This is fixed by 48f73ee666a264d23716ff6bb671cad836b65ccf -- 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 51559] New: Variable not visible at Og
https://bugs.llvm.org/show_bug.cgi?id=51559
Bug ID: 51559
Summary: Variable not visible at Og
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: art...@diag.uniroma1.it
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Comment:
When stepping on line 4 the variable g_3012 is not visible.
Steps to reproduce bug:
root@e60e0a2bba1a:/home/stepping/output# clang -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
957334382cd12ec07b46c0ddfdcc220731f6d80f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
root@e60e0a2bba1a:/home/stepping/output# lldb -v
lldb version 14.0.0 (https://github.com/llvm/llvm-project.git revision
957334382cd12ec07b46c0ddfdcc220731f6d80f)
clang revision 957334382cd12ec07b46c0ddfdcc220731f6d80f
llvm revision 957334382cd12ec07b46c0ddfdcc220731f6d80f
root@e60e0a2bba1a:/home/stepping/output# cat a.c
int g_97 ;
static short g_3012 ;
void func_30() {
g_97 = g_3012;
}
int main() {
{
func_30();
}
}
root@e60e0a2bba1a:/home/stepping/output# cat -n a.c
1 int g_97 ;
2 static short g_3012 ;
3 void func_30() {
4 g_97 = g_3012;
5 }
6 int main() {
7 {
8func_30();
9 }
10 }
root@e60e0a2bba1a:/home/stepping/output# clang -g -Og a.c -o opt
root@e60e0a2bba1a:/home/stepping/output# lldb opt
(lldb) target create "opt"
Current executable set to '/home/stepping/output/opt' (x86_64).
(lldb) b main
Breakpoint 1: where = opt`main [inlined] func_30 at a.c:4:15, address =
0x00400490
(lldb) r
Process 68731 launched: '/home/stepping/output/opt' (x86_64)
Process 68731 stopped
* thread #1, name = 'opt', stop reason = breakpoint 1.1
frame #0: 0x00400490 opt`main [inlined] func_30 at a.c:4:15
1int g_97 ;
2 static short g_3012 ;
3 void func_30() {
-> 4 g_97 = g_3012;
5 }
6 int main() {
7 {
(lldb) p g_3012
error: expression failed to parse:
error: :1:1: use of undeclared identifier 'g_3012'
g_3012
--
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 51560] New: Defaulted consteval default constructor that performs no initialization is not rejected
https://bugs.llvm.org/show_bug.cgi?id=51560
Bug ID: 51560
Summary: Defaulted consteval default constructor that performs
no initialization is not rejected
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Keywords: accepts-invalid
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangb...@nondot.org
Reporter: johel...@gmail.com
CC: blitzrak...@gmail.com, erik.pilking...@gmail.com,
johel...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
See https://godbolt.org/z/Gc4MTfdr7.
```C++
struct X{
int i;
consteval X() = default;
// consteval X() {}
};
int main () {
auto x = X();
(void)x;
}
```
See also https://eel.is/c++draft/class.default.ctor#4, particularly
https://eel.is/c++draft/class.default.ctor#4.sentence-3:
> If that user-written default constructor would be ill-formed, the program is
> ill-formed.
--
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 51561] New: Wrong Stepping Behaviour at Og
https://bugs.llvm.org/show_bug.cgi?id=51561
Bug ID: 51561
Summary: Wrong Stepping Behaviour at Og
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: art...@diag.uniroma1.it
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
Comment:
After stepping on line 27, the debugger steps back inside the main function on
line 39 and then it comes back at line 27 (The disassembly wrongly shows that
lines 39 and 27 are associated with nop instructions only).
Steps to reproduce bug:
root@c79e7fb993cd:/home/stepping/output# clang -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
957334382cd12ec07b46c0ddfdcc220731f6d80f)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Selected multilib: .;@m64
root@c79e7fb993cd:/home/stepping/output# lldb -v
lldb version 14.0.0 (https://github.com/llvm/llvm-project.git revision
957334382cd12ec07b46c0ddfdcc220731f6d80f)
clang revision 957334382cd12ec07b46c0ddfdcc220731f6d80f
llvm revision 957334382cd12ec07b46c0ddfdcc220731f6d80f
root@c79e7fb993cd:/home/stepping/output# cat a.c
char g_432[2][1][3] ;
int g_7714, g_15741, a ;
int g_11542[8] ;
short b[3][1];
short safe_add_func_int16_t_s_s( c, d ) {
return d;
}
short safe_sub_func_int16_t_s_s( c, d ) {
return 0;
}
short safe_mod_func_int16_t_s_s( c, d ) {
return 0;
}
short safe_sub_func_uint16_t_u_u( c, d ) {
return d;
}
short e() {
char p_14 = 0;
int p_13 = 0;
int l_17443[][5][2] = {
0}
;
char l_17448[][3] = {
3, 1, 7, 5 }
;
short l_17449 = 0;
g_7714 =
(safe_sub_func_int16_t_s_s((safe_mod_func_int16_t_s_s((p_14 != 0x217B),
0x031E)), (p_13 | l_17443[0][4][1] < p_14) <
(safe_sub_func_uint16_t_u_u(((safe_add_func_int16_t_s_s(p_14, (g_15741 <
g_432[1][0][2]))) <= g_11542[7]), l_17448[1][2]))) || 0x379B6C12) <
l_17449;
return 1;
}
void func_2(c) {
a = 0;
for (;
a < 3;
a++){
b[a][0] = 3;
}
}
int main (){
func_2( e() );
}
root@c79e7fb993cd:/home/stepping/output# cat -n a.c
1 char g_432[2][1][3] ;
2 int g_7714, g_15741, a ;
3 int g_11542[8] ;
4 short b[3][1];
5 short safe_add_func_int16_t_s_s( c, d ) {
6 return d;
7 }
8 short safe_sub_func_int16_t_s_s( c, d ) {
9 return 0;
10 }
11 short safe_mod_func_int16_t_s_s( c, d ) {
12 return 0;
13 }
14 short safe_sub_func_uint16_t_u_u( c, d ) {
15 return d;
16 }
17short e() {
18 char p_14 = 0;
19 int p_13 = 0;
20 int l_17443[][5][2] = {
21 0}
22 ;
23 char l_17448[][3] = {
24 3, 1, 7, 5 }
25 ;
26 short l_17449 = 0;
27 g_7714 =
(safe_sub_func_int16_t_s_s((safe_mod_func_int16_t_s_s((p_14 != 0x217B),
0x031E)), (p_13 | l_17443[0][4][1] < p_14) <
(safe_sub_func_uint16_t_u_u(((safe_add_func_int16_t_s_s(p_14, (g_15741 <
g_432[1][0][2]))) <= g_11542[7]), l_17448[1][2]))) || 0x379B6C12) <
l_17449;
28 return 1;
29 }
30 void fu
[llvm-bugs] [Bug 51562] New: Disable LDS pass on 13
https://bugs.llvm.org/show_bug.cgi?id=51562 Bug ID: 51562 Summary: Disable LDS pass on 13 Product: OpenMP Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Clang Compiler Support Assignee: unassignedclangb...@nondot.org Reporter: jonathanchesterfi...@gmail.com CC: llvm-bugs@lists.llvm.org Spun out from 51528. https://reviews.llvm.org/D104962 50ad3478bdd3f0643ee94f6663293af5b3c27afe This patch disables an amdgpu LDS memory pass that broke codegen for openmp. It missed the llvm-13 branch narrowly. Revert in place had a lot of conflicts so the patch toggles the command line flag and fixes up tests. The conflict for applying directly to llvm-13 is llc-pipeline.ll where the change should be to drop this pass from the list. I can fix up the commit such that it applies cleanly to 13 (probably by making a new, equivalent one). If I do so, where should I put it so that it can be cherry-picked? I think the github repo will block me from creating a branch with it on. -- 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 51430] [libc++][PowerPC] midpoint.float.pass.cpp test failure for 13.0.0-rc1 on PowerPC
https://bugs.llvm.org/show_bug.cgi?id=51430 Louis Dionne changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||23ba3732246a418e52d6d9ca17b ||45816ade4dc6d --- Comment #7 from Louis Dionne --- Thanks for the patch! I committed the fix to main as 4bef7a8ff169d6f9a0a253105576ac8a68430702 and cherry-picked it to release/13.x as 23ba3732246a418e52d6d9ca17b45816ade4dc6d. -- 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 51430, which changed state. Bug 51430 Summary: [libc++][PowerPC] midpoint.float.pass.cpp test failure for 13.0.0-rc1 on PowerPC https://bugs.llvm.org/show_bug.cgi?id=51430 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 51563] New: incorrect conversion of sqrdmulh+sqsub to sqrdmlsh
https://bugs.llvm.org/show_bug.cgi?id=51563 Bug ID: 51563 Summary: incorrect conversion of sqrdmulh+sqsub to sqrdmlsh Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: LLVM Codegen Assignee: unassignedclangb...@nondot.org Reporter: jz...@google.com CC: llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk, sam.par...@arm.com, sjoerd.mei...@arm.com Created attachment 25180 --> https://bugs.llvm.org/attachment.cgi?id=25180&action=edit repro The sequence of sqrdmulh followed by sqsub is being converted to sqrdmlsh which shifts the rounding from the first multiply to the result causing an off by one in some cases. gcc (tested with aarch64-linux-gnu-gcc (Debian 10.2.1-6+build2) 10.2.1 20210110) does not perform this conversion. Reproduced with llvmorg-14-init-1836-ge4888be74e34 and releases going back to 3.9.1. # repros with -O2/-O3, other levels aside from 0 untested. $ clang -march=armv8.1-a -target aarch64-pc-linux-gnu -O2 \ sqrdmulh_sqsub-sqrdmlsh-repro.c See also: https://godbolt.org/z/zhKnMT15s https://chromium.googlesource.com/codecs/libgav1/+/65bb0dae17596e88ec33cba5d53d1ce54e2fcfcf non_opt:// @non_opt sub sp, sp, #64 // =64 moviv0.8h, #1, lsl #8 str q0, [sp, #48] moviv0.8h, #1 str q0, [sp, #32] ldr q0, [sp, #48] mov w8, #42944 dup v1.8h, w8 sqrdmulhv0.8h, v0.8h, v1.8h str q0, [sp, #16] ldr q0, [sp, #32] ldr q1, [sp, #16] sqsub v0.8h, v0.8h, v1.8h str q0, [sp] ldr q0, [sp] add sp, sp, #64 // =64 ret opt:// @opt mov w8, #42944 moviv1.8h, #1, lsl #8 dup v2.8h, w8 moviv0.8h, #1 sqrdmlshv0.8h, v1.8h, v2.8h ret -- 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 51529] Truncation to i1 generates invalid value
https://bugs.llvm.org/show_bug.cgi?id=51529 Robin Voetter changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Robin Voetter --- Yes, it looks like this is resolved in llvm trunk. I guess that means this issue can now be resolved. Related: https://github.com/ziglang/zig/commit/47f7ed1c4cb8acf7fed99a057fb84202962e4b1b -- 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 46874] GVNHoist hoists a load above a null check
https://bugs.llvm.org/show_bug.cgi?id=46874 hiraditya changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from hiraditya --- patch landed to the main 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
[llvm-bugs] [Bug 51531] wrong code at -O3 on x86_64-linux-gnu
https://bugs.llvm.org/show_bug.cgi?id=51531 Sanjay Patel changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Sanjay Patel --- I think it's safe to resolve this report. I reverted the offending patch with: https://reviews.llvm.org/rGec54e275f56cc042eb9c25acd And added a minimal test based on this example: https://reviews.llvm.org/rG00a50f2617849d0f374d8771f ...so we should not fail in the same way. There's still an open question about another potential bug discussed in: https://reviews.llvm.org/D106056 -- 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] 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::Instruc
https://bugs.llvm.org/show_bug.cgi?id=51553 Sanjay Patel changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||spatel+l...@rotateright.com --- Comment #1 from Sanjay Patel --- This bug was introduced with: https://reviews.llvm.org/rGcfb6dfcbd13b417f83d8a There was a similar report posted after commit in: https://reviews.llvm.org/D108201 Should be fixed with: https://reviews.llvm.org/rGdd19f342fa21 -- 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 48528] __builtin_va_start assumes it can pass SSE registers when using -Xclang -msoft-float -Xclang -no-implicit-float, causing assertion errors
https://bugs.llvm.org/show_bug.cgi?id=48528 Robbert Haarman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Robbert Haarman --- This was fixed in D104001. -- 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 51564] New: IRMover warning "Linking two modules of different target triples" crashes clang
https://bugs.llvm.org/show_bug.cgi?id=51564 Bug ID: 51564 Summary: IRMover warning "Linking two modules of different target triples" crashes clang Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: l...@inglorion.net CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk See https://bugs.chromium.org/p/chromium/issues/detail?id=1128437 This is a ThinLTO build, where clang is invoked with -fthinlto-index to generate machine code. IRMover.cpp contains code to check that when linking two IR modules together, their target triples are compatible. In this case they are not, so a warning diagnostic is generated. The diagnostic is handled by BackendConsumer::DiagnosticHandlerImpl in clang/lib/CodeGen/CodeGenAction.cpp. This contains an assert that CurLinkModule is set. When LLVM is built with asserts enabled, this assert will crash the compiler, even if the diagnostic never results in a message to the user. Immediately after that assert, the diagnostic is in fact ignored, so we're crashing the compiler for a diagnostic that we never surface. -- 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 51565] New: Missing transformation rotate(X, Z) == rotate(Y, Z) ---> X == Y
https://bugs.llvm.org/show_bug.cgi?id=51565
Bug ID: 51565
Summary: Missing transformation rotate(X,Z) == rotate(Y,Z) --->
X == Y
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
// Rotate(X,Z) == Rotate(Y,Z) ---> X == Y
// Rotate(X,Z) != Rotate(Y,Z) ---> X != Y
bool test(unsigned long long x, unsigned long long y) {
unsigned long long rx = (x << 32) | (x >> 32);
unsigned long long ry = (y << 32) | (y >> 32);
return rx != ry;
}
Trunk -O2:
test(unsigned long long, unsigned long long): #
@test(unsigned long long, unsigned long long)
rol rdi, 32
rol rsi, 32
cmp rdi, rsi
setne al
ret
https://godbolt.org/z/Kb6zr8Wa3
Alive:
https://alive2.llvm.org/ce/z/HuEvjC
--
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 51566] New: Missing transformation rotate(x) == 0 to x == 0
https://bugs.llvm.org/show_bug.cgi?id=51566
Bug ID: 51566
Summary: Missing transformation rotate(x) == 0 to x == 0
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
bool test1(unsigned long long x)
{
unsigned long long r = (x << 32) | (x >> 32);
return r != 0;
}
bool test2(unsigned long long x)
{
unsigned long long r = (x << 32) | (x >> 32);
return r == ~0ULL;
}
Trunk -O3:
test1(unsigned long long): # @test1(unsigned long
long)
rol rdi, 32
testrdi, rdi
setne al
ret
test2(unsigned long long): # @test2(unsigned long
long)
rol rdi, 32
cmp rdi, -1
seteal
ret
test3(unsigned long long): # @test3(unsigned long
long)
rol rdi, 32
testrdi, rdi
setne al
ret
Current codegen:
https://godbolt.org/z/q78xxhWe4
define i1 @src(i64 %0) {
%1:
%2 = fshr i64 %0, i64 %0, i64 32
%3 = icmp ne i64 %2, 0
ret i1 %3
}
=>
define i1 @tgt(i64 %0) {
%1:
%2 = icmp ne i64 %0, 0
ret i1 %2
}
Transformation seems to be correct!
define i1 @src(i64 %0) {
%1:
%2 = fshr i64 %0, i64 %0, i64 32
%3 = icmp ne i64 %2, -1
ret i1 %3
}
=>
define i1 @tgt(i64 %0) {
%1:
%2 = icmp ne i64 %0, -1
ret i1 %2
}
Transformation seems to be correct!
Alive:
https://alive2.llvm.org/ce/z/kmrBvv
--
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 51567] New: Missing transformation rotr(X, C1) == C2 --> X == C3
https://bugs.llvm.org/show_bug.cgi?id=51567
Bug ID: 51567
Summary: Missing transformation rotr(X,C1) == C2 --> X == C3
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
// rotr(X, C1) == C2 --> X == C3 where C3 = rotl(C2, C1)
// rotl(X,C1) == C2 --> X == C3 where C3 = rotr(C2,C1)
bool foo(unsigned int x)
{
unsigned int rx = rotr(x, 7);
return rx == 5;
}
bool bar(unsigned int x)
{
return x == rotl(5, 7);
}
Trunk -O2:
foo(unsigned int):# @foo(unsigned int)
rol edi, 25
cmp edi, 5
seteal
ret
bar(unsigned int):# @bar(unsigned int)
cmp edi, 640
seteal
ret
Current codegen:
https://godbolt.org/z/xb1vPa5Pq
Alive:
https://alive2.llvm.org/ce/z/GdY8Jm
--
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 51568] New: Better codegen for truncated bswap
https://bugs.llvm.org/show_bug.cgi?id=51568
Bug ID: 51568
Summary: Better codegen for truncated bswap
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
unsigned int swap_ull(unsigned long long value)
{
return ((value & 0x00ffull) << 56)
| ((value & 0xff00ull) << 40)
| ((value & 0x00ffull) << 24)
| ((value & 0xff00ull) << 8)
| ((value & 0x00ffull) >> 8)
| ((value & 0xff00ull) >> 24)
| ((value & 0x00ffull) >> 40)
| ((value & 0xff00ull) >> 56);
}
unsigned int swap_ull_builtin(unsigned long long value)
{
return __builtin_bswap64(value);
}
Trunk -O3:
swap_ull(unsigned long long): # @swap_ull(unsigned
long long)
movabs rax, 72057589742960640
and rax, rdi
bswap rax
shr rdi, 56
or eax, edi
ret
swap_ull_builtin(unsigned long long): #
@swap_ull_builtin(unsigned long long)
mov rax, rdi
bswap rax
ret
ICC -O3:
swap_ull(unsigned long long):
bswap rdi #10.51
mov eax, edi #10.51
ret #10.51
swap_ull_builtin(unsigned long long):
bswap rdi #15.12
mov eax, edi #15.12
ret #15.12
unsigned int swap_ull(unsigned long long value)
{
return ((value & 0x00ffull) << 56)
| ((value & 0xff00ull) << 40)
| ((value & 0x00ffull) << 24)
| ((value & 0xff00ull) << 8)
| ((value & 0x00ffull) >> 8)
| ((value & 0xff00ull) >> 24)
| ((value & 0x00ffull) >> 40)
| ((value & 0xff00ull) >> 56);
}
unsigned int swap_ull_builtin(unsigned long long value)
{
return __builtin_bswap64(value);
}
define i32 @src(i64 %0) {
%1:
%2 = and i64 %0, 72057594037927935
%3 = bswap i64 %2
%4 = lshr i64 %0, 56
%5 = or i64 %3, %4
%6 = trunc i64 %5 to i32
ret i32 %6
}
=>
define i32 @tgt(i64 %0) {
%1:
%2 = bswap i64 %0
%3 = trunc i64 %2 to i32
ret i32 %3
}
Transformation seems to be correct!
https://alive2.llvm.org/ce/z/loQjOQ
--
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 51569] New: Emitted binary code changes when -g is enabled at -O0 -m32
https://bugs.llvm.org/show_bug.cgi?id=51569
Bug ID: 51569
Summary: Emitted binary code changes when -g is enabled at -O0
-m32
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: tlw...@uwaterloo.ca
CC: cn...@uwaterloo.ca, llvm-bugs@lists.llvm.org
Blocks: 37728
The .text section for the following program (program.c) changes after toggling
the -g flag.
$ cat program.c
int a, b;
void c() {
for (;;)
;
}
int main() {}
$
$ clang-trunk -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
3890ce708d4f94d0326172650ce22262f6b56661)
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
$
$ clang-trunk -c -m32 -O0 program.c ; objdump --disassemble --section=.text
program.o > no_g.txt
$ clang-trunk -c -m32 -O0 -g program.c ; objdump --disassemble --section=.text
program.o > g.txt
$ diff no_g.txt g.txt
10,11c10,11
<3: e9 00 00 00 00 jmp8
<8: e9 fb ff ff ff jmp8
---
>3: e9 00 00 00 00 jmp8
>8: e9 fb ff ff ff jmp8
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=37728
[Bug 37728] [meta] Make llvm passes debug info invariant
--
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 51570] New: Emitted binary code changes when -g is enabled at -m32 -O1
https://bugs.llvm.org/show_bug.cgi?id=51570
Bug ID: 51570
Summary: Emitted binary code changes when -g is enabled at -m32
-O1
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: tlw...@uwaterloo.ca
CC: cn...@uwaterloo.ca, llvm-bugs@lists.llvm.org
Blocks: 37728
The .text section for the following program (program.c) changes after toggling
the -g flag.
$ cat program.c
struct a {
int b[100];
} c, d;
__attribute__((noinline)) struct a e() { return d; }
int main() { c = e(); }
$
$ clang-trunk -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
3890ce708d4f94d0326172650ce22262f6b56661)
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
$
$ clang-trunk -c -m32 -O1 program.c ; objdump --disassemble --section=.text
program.o > no_g.txt
$ clang-trunk -c -m32 -O1 -g program.c ; objdump --disassemble --section=.text
program.o > g.txt
$ diff no_g.txt g.txt
26,39c26,40
< 31: 81 ec a4 01 00 00 sub$0x1a4,%esp
< 37: 8d 74 24 14 lea0x14(%esp),%esi
< 3b: 56 push %esi
< 3c: e8 fc ff ff ff call 3d
< 41: 83 c4 08add$0x8,%esp
< 44: 68 90 01 00 00 push $0x190
< 49: 56 push %esi
< 4a: 68 00 00 00 00 push $0x0
< 4f: e8 fc ff ff ff call 50
< 54: 83 c4 10add$0x10,%esp
< 57: 31 c0 xor%eax,%eax
< 59: 81 c4 98 01 00 00 add$0x198,%esp
< 5f: 5e pop%esi
< 60: c3 ret
---
> 31: 81 ec 98 01 00 00 sub$0x198,%esp
> 37: 83 ec 0csub$0xc,%esp
> 3a: 8d 74 24 14 lea0x14(%esp),%esi
> 3e: 56 push %esi
> 3f: e8 fc ff ff ff call 40
> 44: 83 c4 08add$0x8,%esp
> 47: 68 90 01 00 00 push $0x190
> 4c: 56 push %esi
> 4d: 68 00 00 00 00 push $0x0
> 52: e8 fc ff ff ff call 53
> 57: 83 c4 10add$0x10,%esp
> 5a: 31 c0 xor%eax,%eax
> 5c: 81 c4 98 01 00 00 add$0x198,%esp
> 62: 5e pop%esi
> 63: c3 ret
Referenced Bugs:
https://bugs.llvm.org/show_bug.cgi?id=37728
[Bug 37728] [meta] Make llvm passes debug info invariant
--
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 51571] New: Emitted binary code changes at -O0 when compiling through -S
https://bugs.llvm.org/show_bug.cgi?id=51571
Bug ID: 51571
Summary: Emitted binary code changes at -O0 when compiling
through -S
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: tlw...@uwaterloo.ca
CC: cn...@uwaterloo.ca, llvm-bugs@lists.llvm.org
The .text section of program.c changes when the program is compiled through -S.
$ cat program.c
int a;
void b() {
if (a)
;
}
int main() {}
$
$ clang-trunk -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
3890ce708d4f94d0326172650ce22262f6b56661)
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
$
$ clang-trunk -O0 -c program.c ; objdump --disassemble --section=.text
program.o > no_s.txt
$ clang-trunk -O0 -S program.c ; clang-trunk -O0 -c program.s ; objdump
--disassemble --section=.text program.o > s.txt
$ diff s.txt no_s.txt
12,18c12,16
c: 0f 84 05 00 00 00 je 17
> 12: e9 00 00 00 00 jmpq 17
> 17: 5d pop%rbp
> 18: c3 retq
> 19: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
--
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 51572] New: clang-11.0.1 crashes on FreeBSD 14-CURRENT on the minitube project
https://bugs.llvm.org/show_bug.cgi?id=51572 Bug ID: 51572 Summary: clang-11.0.1 crashes on FreeBSD 14-CURRENT on the minitube project 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 -- 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
