[llvm-bugs] [Bug 46396] New: WebAssembly exception handling catchpads cannot be addressed sometimes
https://bugs.llvm.org/show_bug.cgi?id=46396 Bug ID: 46396 Summary: WebAssembly exception handling catchpads cannot be addressed sometimes Product: libraries Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: Backend: WebAssembly Assignee: unassignedb...@nondot.org Reporter: sascha.braun@googlemail.com CC: llvm-bugs@lists.llvm.org Created attachment 23634 --> https://bugs.llvm.org/attachment.cgi?id=23634&action=edit code sample (cpp) -- I think this shall be forwarded to Heejin Ahn. -- Hi, I'm in the process of implementing several WebAssembly VMs, including EH, working with what is so far already present in LLVM. I think there is a bug in how codegen is done when catchpads are nested. The EH table I think is fine. Please see attached cpp sample. Function test23any_nest1_llvm: I think it is impossible to execute the code in the inner catch for both test3class and test5class. One catchpad can be executed if my _Unwind_CallPersonality() writes it's according EH table entry back to memory address 0. Function test23any_nest1: Here it is ok. Inner CPs for both types can be exec'd, I think it is because catches for both types are also present in the outer try/catch. My assumption is it is related to how child catchpads are deleted in 'wasmehlateprepare'. You can contact me directly sascha.braun@googlemail.com. If I am wrong I would be grateful if you could point out what value _Unwind_CallPersonality shall write to memory addr 0 to select the catch for test3class or test5class. Many Thanks Sascha -- 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 46397] New: Wrong backtrace infromation at Og
https://bugs.llvm.org/show_bug.cgi?id=46397
Bug ID: 46397
Summary: Wrong backtrace infromation at Og
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: DebugInfo
Assignee: unassignedb...@nondot.org
Reporter: massare...@diag.uniroma1.it
CC: jdevliegh...@apple.com, keith.wal...@arm.com,
llvm-bugs@lists.llvm.org,
paul_robin...@playstation.sony.com
At line 11 backtrace information is wrong.
$ cat -n a.c
1 int a, b;
2 static int *c = &a;
3 int *d = &c;
4 int e = 1;
5 char(f)(g) { return g; }
6 void h(int *g) {
7g || b;
8if (a)
9 ;
10else
11 d = f(1);
12 }
13 int *i() { return c; }
14 int main() {
15int *j = i();
16h(j);
17 }
$ cat a.c
int a, b;
static int *c = &a;
int *d = &c;
int e = 1;
char(f)(g) { return g; }
void h(int *g) {
g || b;
if (a)
;
else
d = f(1);
}
int *i() { return c; }
int main() {
int *j = i();
h(j);
}
$ clang -v
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
c143db3b1032042193c152790bcefe34365e6d6c)
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
$ lldb -v
lldb version 11.0.0
clang revision c143db3b1032042193c152790bcefe34365e6d6c
llvm revision c143db3b1032042193c152790bcefe34365e6d6c
$ gdb -v
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
$ clang -Og -g -o out a.c
$ lldb out
(lldb) target create "out"
Current executable set to 'out' (x86_64).
(lldb) b h
Breakpoint 1: where = out`h + 1 at a.c:8:7, address = 0x00400491
(lldb) r
Process 330 launched: 'out' (x86_64)
Process 330 stopped
* thread #1, name = 'out', stop reason = breakpoint 1.1
frame #0: 0x00400491 out`h(g=0x00601044) at a.c:8:7
5char(f)(g) { return g; }
6void h(int *g) {
7 g || b;
-> 8 if (a)
9;
10 else
11 d = f(1);
(lldb) bt
* thread #1, name = 'out', stop reason = breakpoint 1.1
* frame #0: 0x00400491 out`h(g=0x00601044) at a.c:8:7
frame #1: 0x004004de out`main at a.c:16:3
frame #2: 0x77a05b97 libc.so.6`__libc_start_main + 231
frame #3: 0x004003ba out`_start + 42
(lldb) s
Process 330 stopped
* thread #1, name = 'out', stop reason = step in
frame #0: 0x0040049c out`h(g=0x00601044) at a.c:11:9
8 if (a)
9;
10 else
-> 11 d = f(1);
12 }
13 int *i() { return c; }
14 int main() {
(lldb) bt
* thread #1, name = 'out', stop reason = step in
* frame #0: 0x0040049c out`h(g=0x00601044) at a.c:11:9
frame #1: 0x00601044 out`__TMC_END__ + 4
frame #2: 0x004004de out`main at a.c:16:3
frame #3: 0x77a05b97 libc.so.6`__libc_start_main + 231
frame #4: 0x004003ba out`_start + 42
(lldb)
$ gdb out
(gdb) b h
Breakpoint 1 at 0x400491: file a.c, line 8.
(gdb) r
Starting program: /home/stepping/output/opt
Breakpoint 1, h (g=0x601044 ) at a.c:8
8 if (a)
(gdb) bt
#0 h (g=0x601044 ) at a.c:8
#1 0x004004de in main () at a.c:16
(gdb) s
11 d = f(1);
(gdb) bt
#0 h (g=0x601044 ) at a.c:11
#1 0x004004de in main () at a.c:16
--
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 46398] New: Wrong backtrace infromation at Og
https://bugs.llvm.org/show_bug.cgi?id=46398
Bug ID: 46398
Summary: Wrong backtrace infromation at Og
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: massare...@diag.uniroma1.it
CC: jdevliegh...@apple.com, llvm-bugs@lists.llvm.org
At line 10 backtrace information is wrong.
$ cat a.c
int k = 0, a;
int *b = &a;
int c = 2;
short d = 2;
void e() { --d; }
int *f() {
if (a)
e();
else
return b;
}
int main() {
f();
f();
}
$ cat -n a.c
1 int k = 0, a;
2 int *b = &a;
3 int c = 2;
4 short d = 2;
5 void e() { --d; }
6 int *f() {
7if (a)
8 e();
9else
10 return b;
11 }
12 int main() {
13f();
14f();
15 }
$ clang -v
clang version 11.0.0 (https://github.com/llvm/llvm-project.git
c143db3b1032042193c152790bcefe34365e6d6c)
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
$ lldb -v
lldb version 11.0.0
clang revision c143db3b1032042193c152790bcefe34365e6d6c
llvm revision c143db3b1032042193c152790bcefe34365e6d6c
$ gdb -v
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
$ clang -Og -g -o out a.c
$ lldb out
(lldb) target create "out"
Current executable set to 'out' (x86_64).
(lldb) b main
Breakpoint 1: where = out`main + 1 at a.c:13:3, address = 0x004004b1
(lldb) r
Process 123 launched: 'out' (x86_64)
Process 123 stopped
* thread #1, name = 'out', stop reason = breakpoint 1.1
frame #0: 0x004004b1 out`main at a.c:13:3
10 return b;
11 }
12 int main() {
-> 13 f();
14 f();
15 }
(lldb) n
Process 123 stopped
* thread #1, name = 'out', stop reason = step over
frame #0: 0x004004b6 out`main at a.c:14:3
11 }
12 int main() {
13 f();
-> 14 f();
15 }
(lldb) s
Process 123 stopped
* thread #1, name = 'out', stop reason = step in
frame #0: 0x00400491 out`f at a.c:7:7
4short d = 2;
5void e() { --d; }
6int *f() {
-> 7 if (a)
8e();
9 else
10 return b;
(lldb) bt
* thread #1, name = 'out', stop reason = step in
* frame #0: 0x00400491 out`f at a.c:7:7
frame #1: 0x004004bb out`main at a.c:14:3
frame #2: 0x77a05b97 libc.so.6`__libc_start_main + 231
frame #3: 0x004003ba out`_start + 42
(lldb) s
Process 123 stopped
* thread #1, name = 'out', stop reason = step in
frame #0: 0x004004a1 out`f at a.c:10:12
7 if (a)
8e();
9 else
-> 10 return b;
11 }
12 int main() {
13 f();
(lldb) bt
* thread #1, name = 'out', stop reason = step in
* frame #0: 0x004004a1 out`f at a.c:10:12
frame #1: 0x00601040 out`k + 4
frame #2: 0x004004bb out`main at a.c:14:3
frame #3: 0x77a05b97 libc.so.6`__libc_start_main + 231
frame #4: 0x004003ba out`_start + 42
(lldb) exit
$ gdb out
(gdb) b main
Breakpoint 1 at 0x4004b1: file a.c, line 13.
(gdb) r
Starting program: out
Breakpoint 1, main () at a.c:13
13f();
(gdb) s
f () at a.c:7
7 if (a)
(gdb) s
10 return b;
(gdb) s
11 }
(gdb) s
main () at a.c:14
14f();
(gdb) s
f () at a.c:7
7 if (a)
(gdb) bt
#0 f () at a.c:7
#1 0x004004bb in main () at a.c:14
(gdb) s
10 return b;
(gdb) bt
#0 f () at a.c:10
#1 0x004004bb in main () at a.c:14
(gdb)
--
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 46399] New: __NSStackBlock__ cant't be copy to __NSMallocBlock__ in arc
https://bugs.llvm.org/show_bug.cgi?id=46399
Bug ID: 46399
Summary: __NSStackBlock__ cant't be copy to __NSMallocBlock__
in arc
Product: clang
Version: trunk
Hardware: Other
OS: other
Status: NEW
Severity: normal
Priority: P
Component: LLVM Codegen
Assignee: unassignedclangb...@nondot.org
Reporter: sunboh...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
The follow code will be crash in iOS.
-(NSArray*)getBlockArray
{
int num = 916;
return [NSArray arrayWithObjects:
^{ NSLog(@"this is block 0:%i", num); },
^{ NSLog(@"this is block 1:%i", num); },
^{ NSLog(@"this is block 2:%i", num); },
nil];
}
- (void)forTest
{
int a = 10;
int b = 20;
}
- (void)test
{
NSArray* blockArr = [self getBlockArray];
[self forTest];
void (^blockObject)(void);
for(blockObject in blockArr){
blockObject();
}
===
And the follow code will print blocks with different type in macOS.
void testBlockArray() {
int val = 10;
NSArray *arr = [NSArray arrayWithObjects:^(){NSLog(@"blk0:%d",
val);},^(){NSLog(@"blk1:%d", val);}, nil];
NSLog(@"%@", arr);
}
(
"<__NSMallocBlock__: 0x63bb6e80>",
"<__NSStackBlock__: 0x7ffedfdf7c10>"
)
==
I try to fix this crash with
https://github.com/sunbohong/llvm-project/commit/7132d1ee82431ee182775cc65d5de1091cb78cde
--
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 46317] [RV64] Wrong libcall emitted
https://bugs.llvm.org/show_bug.cgi?id=46317 Alex Bradbury changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||7622ea5835f0 Status|NEW |RESOLVED --- Comment #2 from Alex Bradbury --- Thank you for the report and fix Kamlesh, closing as this has been fixed now your patch was merged. -- 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 46400] New: Change to print help instead of reading from stdin when running without arguments
https://bugs.llvm.org/show_bug.cgi?id=46400 Bug ID: 46400 Summary: Change to print help instead of reading from stdin when running without arguments Product: tools Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: llvm-readobj Assignee: unassignedb...@nondot.org Reporter: jh7370.2...@my.bristol.ac.uk CC: jh7370.2...@my.bristol.ac.uk, llvm-bugs@lists.llvm.org GNU readelf, when executed with no input files prints the help text. This is fairly standard behaviour for most tools. llvm-readelf does not - it instead tries to read the object from stdin. Reading from stdin seems to not be a particularly useful behaviour for most users, and can also be achieved via a '-' for the input object. We should change llvm-readelf (and llvm-readobj for consistency) to do the same as GNU does. This will necessesitate a number of updates to tests, but otherwise should be fairly straightforward to do (the updates would be to just use '-' instead). -- 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 46348] Assertion failure during report of duplicate symbol error
https://bugs.llvm.org/show_bug.cgi?id=46348 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Fangrui Song --- https://reviews.llvm.org/rGc4d13f72a6599179f34481d6d848e9fce4ba5ef4 -- 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 46263] The lld cannot identify LMA overlapping when the VMA is not specified.
https://bugs.llvm.org/show_bug.cgi?id=46263 Fangrui Song changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Fangrui Song --- https://reviews.llvm.org/rG8ffb2097cc1adf5a0f964006a7633ed1ee4f59d3 -- 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 23569 in oss-fuzz: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-06-19 Type: Bug New issue 23569 by ClusterFuzz-External: llvm:llvm-dwarfdump-fuzzer: Abrt in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23569 Detailed Report: https://oss-fuzz.com/testcase?key=5198545494999040 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: llvm-dwarfdump-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Abrt Crash Address: 0x0001 Crash State: llvm::llvm_unreachable_internal llvm::DataExtractor::getUnsigned llvm::DWARFDataExtractor::getRelocatedValue Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201801290646:201801300702 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5198545494999040 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 23570 in oss-fuzz: llvm:clangd-fuzzer: ASSERT: llvm::sys::path::is_absolute(AbsPath) && "the path is relative"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-06-19 Type: Bug New issue 23570 by ClusterFuzz-External: llvm:clangd-fuzzer: ASSERT: llvm::sys::path::is_absolute(AbsPath) && "the path is relative" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23570 Detailed Report: https://oss-fuzz.com/testcase?key=5361911553327104 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clangd-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: llvm::sys::path::is_absolute(AbsPath) && "the path is relative" clang::clangd::URIForFile::canonicalize clang::clangd::ClangdLSPServer::onDiagnosticsReady Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201908280324:201908290314 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5361911553327104 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 23571 in oss-fuzz: llvm:clang-objc-fuzzer: Segv on unknown address in llvm::llvm_unreachable_internal
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Security_Severity-High Reported-2020-06-19 Type: Bug-Security New issue 23571 by ClusterFuzz-External: llvm:clang-objc-fuzzer: Segv on unknown address in llvm::llvm_unreachable_internal https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23571 Detailed Report: https://oss-fuzz.com/testcase?key=5423964099969024 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-objc-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Segv on unknown address Crash Address: Crash State: llvm::llvm_unreachable_internal clang::Expr::HasSideEffects clang::Expr::HasSideEffects Sanitizer: memory (MSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&range=201911200438:201911230451 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5423964099969024 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 46401] New: [AMDGPU][MC] Some of invalid opcodes can be disassembled but break code emitter
https://bugs.llvm.org/show_bug.cgi?id=46401 Bug ID: 46401 Summary: [AMDGPU][MC] Some of invalid opcodes can be disassembled but break code emitter Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Some limitations have recently been added on use of f16 inline constants (change 5f5f566). As a result many previously valid encodings become invalid. Disassembler is still able to decode them but some of these break code emitter. For example, the following GFX9 code: 0xf9,0x72,0x0a,0x7e,0xf0,0x06,0x86,0x00 may be correctly disassembled to an instruction shown below: v_cvt_f16_u16_sdwa v5, 0x3800 dst_sel:DWORD dst_unused:UNUSED_PAD src0_sel:DWORD However adding '-show-encoding' option breaks code emitter (debug build only). I updated and run all script-generated tests and found out that the issue manifests itself with GFX9 SDWA only. However looks like the problem is more generic. In many cases code emitter manages to encode invalid instructions w/o breakage. We should probably revise errors handling in emitter - either relax some checks or add a mode with these checks disabled. Or we could validate MCInst after disassembly but before dumping encoding. -- 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 46402] New: Missed opportunities for combining or eliminating sequential branches
https://bugs.llvm.org/show_bug.cgi?id=46402 Bug ID: 46402 Summary: Missed opportunities for combining or eliminating sequential branches Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Common Code Generator Code Assignee: unassignedb...@nondot.org Reporter: kh...@kylehuey.com CC: llvm-bugs@lists.llvm.org Created attachment 23635 --> https://bugs.llvm.org/attachment.cgi?id=23635&action=edit LLVM IR for jb X, je X and unconsolidated bounds checks. I'm filing in this in the CodeGen component because it seems like peephole optimizer should catch at least some of this this, but it may be that this belongs elsewhere. Using the latest nightly rustc (which is on LLVM 10), I see code sequences like _ZN5x11rb8protocol3xkb21LatchLockStateRequest17try_parse_request17hb503842b081124b2E: movq%rdi, %rax shrq$40, %rsi cmpb$5, %sil jne .LBB4888_13 cmpq$2, %rcx jb .LBB4888_16 je .LBB4888_16 cmpq$3, %rcx je .LBB4888_16 cmpq$4, %rcx je .LBB4888_16 cmpb$0, 4(%rdx) setne %sil cmpq$5, %rcx je .LBB4888_16 movb5(%rdx), %dil cmpb$4, %dil jae .LBB4888_13 cmpq$6, %rcx je .LBB4888_16 cmpq$7, %rcx je .LBB4888_16 cmpq$8, %rcx je .LBB4888_16 cmpq$9, %rcx je .LBB4888_16 andq$-2, %rcx cmpq$10, %rcx jne .LBB4888_12 .LBB4888_16: movb$0, 1(%rax) movb$1, %cl movb%cl, (%rax) retq .LBB4888_13: movb$1, 1(%rax) movb$1, %cl movb%cl, (%rax) retq .LBB4888_12: movzwl (%rdx), %ecx movb2(%rdx), %r8b movb3(%rdx), %r9b movb6(%rdx), %r10b cmpb$0, 9(%rdx) movzwl 10(%rdx), %edx movw%cx, 2(%rax) movw%dx, 4(%rax) movb%r8b, 6(%rax) movb%r9b, 7(%rax) movb%sil, 8(%rax) movb%dil, 9(%rax) movb%r10b, 10(%rax) setne 11(%rax) xorl%ecx, %ecx movb%cl, (%rax) retq There's at least two missed opportunities to optimize branches here. The first trivial one is that the adjacent `jb X; je X` could be combined into a single `jbe X`. The second, more complicated but bigger win is that a number of these branches checking %rcx could be consolidated. At each point where we check %rcx all values lower than the current comparison value have already been rules out. So every one of those branches is not just a `je LBB4888_16` but effectively a `jbe LBB4888_16`. If the compiler could figure that out it could remove adjacent ones just leaving the last branch to LBB4888_16 in each sequence. Identifying that would remove at least 50% of the branches in this function. The LLVM IR that rustc produces for this function (as taken with llvm-extract) is attached. -- 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 46403] New: [AMDGPU][MC] Incorrect parsing of operand separators of MTBUF instructions
https://bugs.llvm.org/show_bug.cgi?id=46403 Bug ID: 46403 Summary: [AMDGPU][MC] Incorrect parsing of operand separators of MTBUF instructions Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org MTBUF syntax expects that DFMT/NFMT operands are separated by commas, for example: tbuffer_load_format_x v1, off, s[4:7], dfmt:15, s1 However the parser seems to skip next token after DFMT/NFMT without checking that this is a comma. This bug results in hard to understand syntax errors. For example, the following code fails to compile with an error "too few operands for instruction": tbuffer_load_format_x v1, off, s[4:7], dfmt:15 s1 The following code is also compiled w/o any issues: tbuffer_load_format_x v1, off, s[4:7], dfmt:15 nfmt:2 s1 -- 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 46404] New: [AMDGPU][MC] Missing operands of MTBUF are not handled correctly
https://bugs.llvm.org/show_bug.cgi?id=46404 Bug ID: 46404 Summary: [AMDGPU][MC] Missing operands of MTBUF are not handled correctly Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: Backend: AMDGPU Assignee: unassignedb...@nondot.org Reporter: dpreobrazhen...@luxoft.com CC: llvm-bugs@lists.llvm.org Missing soffset operand does not trigger an error but causes assembler crash. An example of failed test: tbuffer_store_format_xyzw v[0:3], v4, s[0:3], dfmt:15 -- 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 46405] New: Calling a function with the address of your own argument produces lots of unnecessary moves
https://bugs.llvm.org/show_bug.cgi?id=46405
Bug ID: 46405
Summary: Calling a function with the address of your own
argument produces lots of unnecessary moves
Product: new-bugs
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedb...@nondot.org
Reporter: josephcsi...@gmail.com
CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org
Consider this code:
void g(long *);
long f(long x) {
g(&x);
return x;
}
With "-O3", it results in this assembly:
f:
pushq %rax
movq%rdi, (%rsp)
movq%rsp, %rdi
callq g
movq(%rsp), %rax
popq%rcx
retq
This does two unnecessary moves, because it wastes both the push and pop to
just update the stack pointer, and then immediately fills in the right value
afterwards.
With "-Os", it results in this assembly:
f:
pushq %rbx
subq$16, %rsp
leaq8(%rsp), %rbx
movq%rdi, (%rbx)
movq%rbx, %rdi
callq g
movq(%rbx), %rax
addq$16, %rsp
popq%rbx
retq
This is a really big mess and is hardly any shorter than "-O0" (in fact, it'd
be longer if not for the frame pointer).
In both cases, it should produce something more like this instead:
f:
pushq %rdi
movq%rsp, %rdi
callq g
popq%rax
retq
Godbolt link: https://godbolt.org/z/aoSMqg
--
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 46406] New: [X86] rsqrt and div generated for 1/sqrt(x * x * x) with -Ofast
https://bugs.llvm.org/show_bug.cgi?id=46406 Bug ID: 46406 Summary: [X86] rsqrt and div generated for 1/sqrt(x * x * x) with -Ofast Product: libraries Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: craig.top...@gmail.com CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com InstCombine transforms sqrt(x * x * x) into fabs(x) * sqrt(x) under fast math. This means (1 / sqrt(x*x*x)) becomes (1 / (fabs(x) * sqrt(x))) which the backend is unable to match to reciprocal sqrt approximation. Instead we do a square root approximation which uses rsqrt followed by a regular divide. Ideally we'd just do the x*x*x and then approximate the reciprocal square root of that. https://godbolt.org/z/fR66c4 -- 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 23575 in oss-fuzz: llvm:clang-fuzzer: Stack-overflow in maybeDiagnoseIDCharCompat
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-06-20 Type: Bug New issue 23575 by ClusterFuzz-External: llvm:clang-fuzzer: Stack-overflow in maybeDiagnoseIDCharCompat https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=23575 Detailed Report: https://oss-fuzz.com/testcase?key=4845348253335552 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffdf6ecffd8 Crash State: maybeDiagnoseIDCharCompat clang::Lexer::LexUnicode clang::Lexer::LexTokenInternal Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=202006170303:202006180303 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4845348253335552 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
