[llvm-bugs] [Bug 39718] New: clang crashes on valid code at -Os and above on x86_64-linux-gnu: fatal error: error in backend: Broken function found, compilation aborted!
https://bugs.llvm.org/show_bug.cgi?id=39718 Bug ID: 39718 Summary: clang crashes on valid code at -Os and above on x86_64-linux-gnu: fatal error: error in backend: Broken function found, compilation aborted! Product: clang Version: unspecified Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: s...@cs.ucdavis.edu CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk Tested with trunk revision 347212. $ clangpolly -v clang version 8.0.0 (http://llvm.org/git/clang.git 8ab54153b8c32d61c5c2251ae490940cbe47a6cc) (http://llvm.org/git/llvm.git 23ff23942df1b56bc58b0282ec762f2aa62c7406) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/su/bin Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Candidate multilib: x32;@mx32 Selected multilib: .;@m64 $ $ clangpolly -O1 small.c; ./a.out $ $ clangpolly -Os small.c Instruction does not dominate all uses! %spec.select = zext i1 %not.tobool2 to i8 %and = and i8 %0, %spec.select in function main fatal error: error in backend: Broken function found, compilation aborted! clang-6: error: clang frontend command failed with exit code 70 (use -v to see invocation) clang version 8.0.0 (http://llvm.org/git/clang.git 8ab54153b8c32d61c5c2251ae490940cbe47a6cc) (http://llvm.org/git/llvm.git 23ff23942df1b56bc58b0282ec762f2aa62c7406) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/su/bin clang-6: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-6: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-6: note: diagnostic msg: /tmp/small-8cd6d5.c clang-6: note: diagnostic msg: /tmp/small-8cd6d5.sh clang-6: note: diagnostic msg: $ char a, e, f; int b, c, d; char g (char h) { return h == 0 ? a : a % h; } int main () { for (; d; d++) b = g (e & (f && (c = 1))); return 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39584, which changed state. Bug 39584 Summary: Merge r345353 into the 7.0 branch : Teach the DominatorTree fallback to recalculation when applying updates to speedup JT (PR37929) https://bugs.llvm.org/show_bug.cgi?id=39584 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39584] Merge r345353 into the 7.0 branch : Teach the DominatorTree fallback to recalculation when applying updates to speedup JT (PR37929)
https://bugs.llvm.org/show_bug.cgi?id=39584 Tom Stellard changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)|r345353 |r345353 r347285 Status|NEW |RESOLVED --- Comment #6 from Tom Stellard --- Merged: r347285 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39717] New: AArch64 MachineOutliner causes performance regression on Firefox
https://bugs.llvm.org/show_bug.cgi?id=39717 Bug ID: 39717 Summary: AArch64 MachineOutliner causes performance regression on Firefox Product: new-bugs Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: mh+l...@glandium.org CC: htmldevelo...@gmail.com, jpaque...@apple.com, llvm-bugs@lists.llvm.org Upgrading from Clang 6 to Clang 7 made Firefox for Android performance regression on aarch64, noticeable as a ~2.5% regression on the speedometer benchmark. After bisection, I found that the cause of the regression is https://github.com/llvm-mirror/llvm/commit/031332e78887f4658e2d7a2f7541827c2ca9baf5, and building with clang 7 with that patch reverted does bring the speedometer score to what it was with clang 6. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 19463, which changed state. Bug 19463 Summary: VLAIS - false positive https://bugs.llvm.org/show_bug.cgi?id=19463 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 19463] VLAIS - false positive
https://bugs.llvm.org/show_bug.cgi?id=19463 Nick Desaulniers changed: What|Removed |Added Status|NEW |RESOLVED CC||ndesaulni...@google.com Resolution|--- |INVALID --- Comment #6 from Nick Desaulniers --- > unsigned long mask[(((num_processors) + (8 * sizeof(long)) - 1) / (8 * > sizeof(long)))]; > I totally agree this looks and smells like VLAIS, but is it? num_processors is not an ICE. As pointed out in comment #2. I removed this from the kernel anyway as pointed out in comment #5. Closing as invalid. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 39708, which changed state. Bug 39708 Summary: Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std' https://bugs.llvm.org/show_bug.cgi?id=39708 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39708] Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'
https://bugs.llvm.org/show_bug.cgi?id=39708 Tom Stellard changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)|r341697 |r341697 r347276 Resolution|--- |FIXED --- Comment #2 from Tom Stellard --- Merged: r347276 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39716] New: [DebugInfo] Unused arguments aren't visible in optimized code.
https://bugs.llvm.org/show_bug.cgi?id=39716 Bug ID: 39716 Summary: [DebugInfo] Unused arguments aren't visible in optimized code. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: apra...@apple.com, fr...@apple.com, jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, r...@google.com, v...@vedantk.com, v...@apple.com, ztur...@google.com * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x00010f84 a.out`fn2(a=, b=, c=) at optout.c:12:10 [opt] 9fn2 (long int a, long int b, long int c) 10 { 11 long int q = 2 * a; -> 12 return fn1 (5, 6, 7); 13 } 14 15 int main(void) { (lldb) frame var (long) a = (long) b = (long) c = (long) q = A gcc-built binary debugged with gdb yields: Breakpoint 1, main () at opt.c:16 16 return fn2(14, 23, 34); (gdb) s fn2 (c=34, b=23, a=14) at opt.c:12 12 return fn1 (5, 6, 7); (gdb) info args c = 34 b = 23 a = 14 Testcase: __attribute__((noinline)) int fn1 (long int x, long int y, long int z) { int l = x * 2; int q = y * z; return l + q; } __attribute__((noinline)) long int fn2 (long int a, long int b, long int c) { long int q = 2 * a; return fn1 (5, 6, 7); } int main(void) { return fn2(14, 23, 34); } -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39715] New: [DebugInfo] Lifetime of function arguments is too short in optimized code.
https://bugs.llvm.org/show_bug.cgi?id=39715 Bug ID: 39715 Summary: [DebugInfo] Lifetime of function arguments is too short in optimized code. Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: apra...@apple.com, fr...@apple.com, jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, r...@google.com, v...@vedantk.com, v...@apple.com, ztur...@google.com Same test case as before: __attribute__((noinline)) int fn1 (long int x, long int y, long int z) { int l = x * 2; int q = y * z; return l + q; } __attribute__((noinline)) long int fn2 (long int a, long int b, long int c) { long int q = 2 * a; return fn1 (5, 6, 7); } int main(void) { return fn2(14, 23, 34); } (built with -O3 -g). lldb session: Process 30254 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step in frame #0: 0x00010f74 a.out`fn1(x=5, y=6, z=7) at optout.c:4:19 [opt] 1__attribute__((noinline)) 2int fn1 (long int x, long int y, long int z) { 3int l = x * 2; -> 4int q = y * z; 5return l + q; 6} 7 (lldb) frame var z (long) z = 7 (lldb) n Process 30254 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x00010f77 a.out`fn1(x=5, y=6, z=) at optout.c:5:18 [opt] 2int fn1 (long int x, long int y, long int z) { 3int l = x * 2; 4int q = y * z; -> 5return l + q; 6} 7 8__attribute__((noinline)) long int (lldb) frame var z (long) z = -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 18896, which changed state. Bug 18896 Summary: Linux kernel ARM: Compiled successfully but final report not generated. https://bugs.llvm.org/show_bug.cgi?id=18896 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 18896] Linux kernel ARM: Compiled successfully but final report not generated.
https://bugs.llvm.org/show_bug.cgi?id=18896 Nick Desaulniers changed: What|Removed |Added Resolution|--- |INVALID CC||ndesaulni...@google.com Status|NEW |RESOLVED --- Comment #3 from Nick Desaulniers --- Please try again compiling with Clang and reopen if you can still reproduce. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 11326] Clang generates incorrect code for structure member offsets on ARM
https://bugs.llvm.org/show_bug.cgi?id=11326 Nick Desaulniers changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4068] [Meta] Compiling the Linux kernel with clang
https://bugs.llvm.org/show_bug.cgi?id=4068 Bug 4068 depends on bug 11326, which changed state. Bug 11326 Summary: Clang generates incorrect code for structure member offsets on ARM https://bugs.llvm.org/show_bug.cgi?id=11326 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 26899] Valarray constructor should have the elements of the array value-initialized as of C++14 standard, but they are initialized using a copy constructor.
https://bugs.llvm.org/show_bug.cgi?id=26899 hst...@ca.ibm.com changed: What|Removed |Added CC||hst...@ca.ibm.com Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from hst...@ca.ibm.com --- The committee has clarified that the user is responsible for not supplying a type where the difference matters: https://cplusplus.github.io/LWG/lwg-defects.html#2699 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 11461 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: val != Map.end() && "unexpected runtime library name"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@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 Proj-llvm Reported-2018-11-19 Type: Bug New issue 11461 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: ASSERT: val != Map.end() && "unexpected runtime library name" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11461 Detailed report: https://oss-fuzz.com/testcase?key=5690233278955520 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--wasm32-O2 Fuzz target binary: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: val != Map.end() && "unexpected runtime library name" llvm::GetLibcallSignature llvm::WebAssemblyMCInstLower::GetExternalSymbolSymbol Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811180234:201811190234 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5690233278955520 Issue filed automatically. See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. 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. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39714] New: -fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill
https://bugs.llvm.org/show_bug.cgi?id=39714 Bug ID: 39714 Summary: -fast-isel=0 for armv7 can result in 4-byte Reload without corresponding 4-byte Spill Product: new-bugs Version: 7.0 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: jholaj...@arxan.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Created attachment 21130 --> https://bugs.llvm.org/attachment.cgi?id=21130&action=edit repro.ll can be use to reproduce the incorrect assembly generated by llc The attached test case demonstrates an issue where lowering armv7 bitcode for iOS using -fast-isel=0 results in a register being reloaded from the stack without first being spilled to the stack. This results in an unknown value being loaded into the register and undefined runtime results. This bug is important because Apple forces use of -fast-isel=0 when re-lowering armv7 bitcode built using Enable Bitcode set to Yes. There is no way to disable use of -fast-isel=0 when submitting bitcode to Apple. Use the following command line with the attached repro.ll: llc -relocation-model=pic -O0 -fast-isel=0 repro.ll -filetype=asm -o repro.s The resultant repro.s will contain the following line: ldr.w r1, [r6, #2500] @ 4-byte Reload The reload of r1 with r6 offset by #2500 was never spilled to the stack. This instruction is reading and unknown value from the stack and populating r1 with it. This leads to undefined runtime behavior. >From the repro.ll file, you can see that a function named printAggregate() is being invoked: call void @printAggregate(%struct.structOfStrings* byval align 4 @structOfStrings2, i32 2) #18 call void @printAggregate(%struct.structOfStrings* byval align 4 @structOfStrings1, i32 1) #18 call void @printAggregate(%struct.structOfStrings* byval align 4 @structOfStrings3, i32 3) #18 In the repro.s file, prior to the first invocation of printAggregate() we can see that the second parameter is populated into r1 via the following instruction: movsr1, #2 This is also the case with the third invocation of printAggregate(): movsr1, #3 It is unclear why the second invocation of printAggregate() does not also use movs, instead trying to Reload r1 from the stack even though it was never spilled. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39713] New: std::alignment_of::value might be different from alignof(T)
https://bugs.llvm.org/show_bug.cgi?id=39713 Bug ID: 39713 Summary: std::alignment_of::value might be different from alignof(T) Product: libc++ Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: unassignedclangb...@nondot.org Reporter: sbe...@google.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Simple repro: #include static_assert(alignof(long long) == std::alignment_of::value); With compiler flags: -std=c++17 -m32 -stdlib=libc++ alignof(long long) == 4 std::alignment_of::value == 8 The problem is that std::alignment_of is using __alignof__ which gives a different result than alignof in this particular case. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39712] New: clang-cl generates more static initializers than VC++ does
https://bugs.llvm.org/show_bug.cgi?id=39712 Bug ID: 39712 Summary: clang-cl generates more static initializers than VC++ does Product: clang Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: enhancement Priority: P Component: C++ Assignee: unassignedclangb...@nondot.org Reporter: brucedaw...@chromium.org CC: blitzrak...@gmail.com, dgre...@apple.com, erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk This is an example of code that VC++ optimizes better than clang-cl. With VC++ there is no static initializer whereas with clang there is: struct my_id { my_id() : v_(0) {} int v_; }; template struct Foo { static my_id id; }; template my_id Foo::id; int main() { Foo::id.v_++; } So, this is a missing optimization in LLVM. LLVM's globalopt pass is supposed to handle this, but it gives up too easily. The COMDAT scheme that Microsoft uses is clever and allows the compiler to optimize this to static initialization without changing the ABI. This was reported in crbug.com/782027 and it leads to eleven static initializers in clang-cl builds of Chrome (chrome.exe, chrome.dll, and chrome_child.dll) that are not present in VC++ builds, coming from the VC++ STL header files. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39711] New: Broken PLT in statically linked binary with -z now -z retpolineplt
https://bugs.llvm.org/show_bug.cgi?id=39711 Bug ID: 39711 Summary: Broken PLT in statically linked binary with -z now -z retpolineplt Product: lld Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org, peter.sm...@linaro.org Hello world test code: % cat hello.c #include int main(int argc, char *argv[]) { printf("Hi\n"); } lld version: % ld.lld --version LLD 6.0.1 (FreeBSD 335540-125) (compatible with GNU linkers) Build test application: % LLD_REPRODUCE=hello.tar cc -g -static -Wl,-zretpolineplt,-znow hello.c -o hello.static-retpoline-now Application segfaults: % ./hello.static-retpoline-now zsh: illegal hardware instruction (core dumped) ./hello.static-retpoline-now We have a PLT entry that jumps to an invalid location: % objdump -S -section=.plt hello.static-retpoline-now hello.static-retpoline-now: file format ELF64-x86-64 Disassembly of section .plt: .plt: 2a0890: 4c 8b 1d a9 5f 00 00movq24489(%rip), %r11 2a0897: e9 d4 ff ff ff jmp -44 <_init+0x8> 2a089c: cc int3 2a089d: cc int3 2a089e: cc int3 2a089f: cc int3 Note that there is a .plt entry here, but no PLT header. Reproducer: https://people.freebsd.org/~emaste/lld/hello.tar.xz See also FreeBSD PR 26 https://bugs.freebsd.org/26 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38083] [debugify] instcombine fail (2) (Instruction with empty DebugLoc in function)
https://bugs.llvm.org/show_bug.cgi?id=38083 Vedant Kumar changed: What|Removed |Added Fixed By Commit(s)||347257 Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 37953] [meta] [debugify] fix -check-debugify failures
https://bugs.llvm.org/show_bug.cgi?id=37953 Bug 37953 depends on bug 38083, which changed state. Bug 38083 Summary: [debugify] instcombine fail (2) (Instruction with empty DebugLoc in function) https://bugs.llvm.org/show_bug.cgi?id=38083 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39106] [meta] 7.0.1 Release Blockers
https://bugs.llvm.org/show_bug.cgi?id=39106 Bug 39106 depends on bug 38987, which changed state. Bug 38987 Summary: (REGRESSION) crash in coverage build: error in backend: File exit not handled before popRegions https://bugs.llvm.org/show_bug.cgi?id=38987 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38987] (REGRESSION) crash in coverage build: error in backend: File exit not handled before popRegions
https://bugs.llvm.org/show_bug.cgi?id=38987 Vedant Kumar changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||347261 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39258] Coverage mapping fails with "File exit not handled before popRegions" on #define'd goto
https://bugs.llvm.org/show_bug.cgi?id=39258 Vedant Kumar changed: What|Removed |Added Fixed By Commit(s)||347262 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 3473] need load/store merging in dag combine
https://bugs.llvm.org/show_bug.cgi?id=3473 Nirav Dave changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||nir...@google.com --- Comment #3 from Nirav Dave --- This functionality was added some time ago. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 21207] DAG Combiner can generate illegal operations
https://bugs.llvm.org/show_bug.cgi?id=21207 Simon Pilgrim changed: What|Removed |Added Status|NEW |RESOLVED Fixed By Commit(s)||347255 Resolution|--- |FIXED --- Comment #3 from Simon Pilgrim --- Legalization on the fly was added some time ago which should avoid this problem. rL347255 makes the op legality testing consistent throughout DAGCombiner::SimplifyNodeWithTwoResults. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39703] unnecessary bit-and in pshufb vector ctlz
https://bugs.llvm.org/show_bug.cgi?id=39703 Simon Pilgrim changed: What|Removed |Added Status|CONFIRMED |RESOLVED Fixed By Commit(s)||347242 Resolution|--- |FIXED --- Comment #2 from Simon Pilgrim --- Fixed in rL347242 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39710] New: Emission of DW_TAG_formal_parameter location is inaccurate on Linux (with -O3)
https://bugs.llvm.org/show_bug.cgi?id=39710 Bug ID: 39710 Summary: Emission of DW_TAG_formal_parameter location is inaccurate on Linux (with -O3) Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: enhancement Priority: P Component: DebugInfo Assignee: unassignedb...@nondot.org Reporter: dav...@freebsd.org CC: apra...@apple.com, fr...@apple.com, jdevliegh...@apple.com, keith.wal...@arm.com, llvm-bugs@lists.llvm.org, r...@google.com, v...@apple.com There has been a lot of talking about about unrecoverable function arguments for optimized builds, so I decided to give it a try to see if there's something that could be done to improve. Take the following test case: __attribute__((noinline)) int fn1 (long int x, long int y, long int z) { int l = x * 2; int q = y * z; return l + q; } __attribute__((noinline)) long int fn2 (long int a, long int b, long int c) { long int q = 2 * a; return fn1 (5, 6, 7); } int main(void) { return fn2(14, 23, 34); } Build with -O3 -g. Set a breakpoint on fn1, and try to print the arguments (e.g. through `frame var`). You'll realize that you can recover them on a recent MacOS (Mojave), but you can't on ubuntu 18.10. I started looking a little bit into why this was the case, to immediately find out the DWARF emission for the formal parameter differs on the two platforms. Namely: MacOS: 0x0043: DW_TAG_formal_parameter DW_AT_location(0x [0x00010f70, 0x00010f74): DW_OP_reg5 RDI [0x00010f74, 0x00010f7c): DW_OP_reg5 RDI) DW_AT_name("x") DW_AT_decl_file ("/Users/davide/llvm-monorepo/llvm-mono/build/bin/optout.c") DW_AT_decl_line (2) DW_AT_type(0x0104 "long int") Linux: 0x0043: DW_TAG_formal_parameter DW_AT_location(0x) DW_AT_name("x") DW_AT_decl_file ("/home/davide/optimized_code/./opt.c") DW_AT_decl_line (2) DW_AT_type(0x00f1 "long int") While the former contains a location list pointing at the register where the debugger should retrieve the argument, the second one contains an empty location list. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39709] New: [X86] Suboptimal code in vXi8 vector multiply reduction
https://bugs.llvm.org/show_bug.cgi?id=39709 Bug ID: 39709 Summary: [X86] Suboptimal code in vXi8 vector multiply reduction 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 Multiplying vXi8 vectors requires widening elements to 16 bits to use vXi16 pmullw then shrinking back to i8. As of r347240 we use punpacklbw/punpackhbw to do the expansion create undef upper elements and we use an AND+PACKUS to merge the high and low unpacked values back together after the two pmullw. When we're doing a horizontal reduction we end up packing after each step and then unpacking at the start of the next step. It would be great if we could combine these size changes away. Some of the packs and unpacks are separated by shuffles to move elements from higher elements to lower elements to do the reduction. We should see if we can handle widening those element movement shuffles as well. These things can be seen in vector-reduce-mul.ll -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 8564] [patch] On Mac OS libLLVM-2.9svn.dylib is linked to be used by tools only
https://bugs.llvm.org/show_bug.cgi?id=8564 Reid Kleckner changed: What|Removed |Added Resolution|--- |FIXED CC||r...@google.com Status|NEW |RESOLVED --- Comment #2 from Reid Kleckner --- We've replaced the autoconf build system since this was filed. Please reopen the bug if you are still affected. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 4370] Debug/Function.o is 700k
https://bugs.llvm.org/show_bug.cgi?id=4370 Reid Kleckner changed: What|Removed |Added Component|System Library |Core LLVM classes Resolution|--- |FIXED Status|NEW |RESOLVED CC||r...@google.com --- Comment #5 from Reid Kleckner --- I think I fixed the real problem this is referring to back in r258774, which replaced the radix-y string prefix generated switch code with a plain binary search. My build (clang-cl, optimizations enabled, debug info enabled, asserts enabled) has a Function.obj that's 2.9MB, so that's quite large relative to these numbers, but the text is very very small, only 38618 bytes. The readonly data is about 500KB, i.e. the tables of intrinsic data. The rest is debug info. I don't think there's anything to do here. We need the intrinsic data tables somewhere. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 12743] PathV2: unique_file("dir%%/file") doesn't create unique directory "dir%%"
https://bugs.llvm.org/show_bug.cgi?id=12743 Reid Kleckner changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||r...@google.com --- Comment #4 from Reid Kleckner --- > This appears to be resolved already, does it not? Marking 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39708] New: Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std'
https://bugs.llvm.org/show_bug.cgi?id=39708 Bug ID: 39708 Summary: Merge r341697 into the 7.0 branch : warn_stdlibcxx_not_found: suggest '-stdlib=libc++' instead of '-std' Product: new-bugs Version: 7.0 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: tstel...@redhat.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org Blocks: 39106 Is it OK to merge the following revision(s) to the 7.0 branch? Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=39106 [Bug 39106] [meta] 7.0.1 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 10314] "bitset::operator[](size_t) const" does not return bool
https://bugs.llvm.org/show_bug.cgi?id=10314 hst...@ca.ibm.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- CC||hst...@ca.ibm.com --- Comment #6 from hst...@ca.ibm.com --- This still fails with trunk: https://wandbox.org/permlink/HnDDdwYxfyfivRbz I am not saying that the proxy type should go, but the problem report should not read as "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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39707] New: Wrong condition evaluation
https://bugs.llvm.org/show_bug.cgi?id=39707 Bug ID: 39707 Summary: Wrong condition evaluation Product: libraries Version: 6.0 Hardware: PC OS: All Status: NEW Severity: release blocker Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: roy...@freebsd.org CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, spatel+l...@rotateright.com Hello, While compiling Xen with clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) on amd64 I came across the following bug. Given this C code: static void init_heap_pages( struct page_info *pg, unsigned long nr_pages) { unsigned long i; bool idle_scrub = false; /* * Some pages may not go through the boot allocator (e.g reserved * memory at boot but released just after --- kernel, initramfs, * etc.). * Update first_valid_mfn to ensure those regions are covered. */ spin_lock(&heap_lock); first_valid_mfn = mfn_min(page_to_mfn(pg), first_valid_mfn); spin_unlock(&heap_lock); if ( system_state < SYS_STATE_active && opt_bootscrub == BOOTSCRUB_IDLE ) idle_scrub = true; for ( i = 0; i < nr_pages; i++ ) { unsigned int nid = phys_to_nid(page_to_maddr(pg+i)); if ( unlikely(!avail[nid]) ) { unsigned long s = mfn_x(page_to_mfn(pg + i)); unsigned long e = mfn_x(mfn_add(page_to_mfn(pg + nr_pages - 1), 1)); bool_t use_tail = (nid == phys_to_nid(pfn_to_paddr(e - 1))) && !(s & ((1UL << MAX_ORDER) - 1)) && (find_first_set_bit(e) <= find_first_set_bit(s)); unsigned long n; n = init_node_heap(nid, mfn_x(page_to_mfn(pg + i)), nr_pages - i, &use_tail); BUG_ON(i + n > nr_pages); if ( n && !use_tail ) { i += n - 1; continue; } if ( i + n == nr_pages ) break; nr_pages -= n; } free_heap_pages(pg + i, 0, scrub_debug || idle_scrub); } } llvm generates the following assembly: Dump of assembler code for function init_heap_pages: 0x82d080223900 <+0>: push %rbp 0x82d080223901 <+1>: mov%rsp,%rbp 0x82d080223904 <+4>: push %r15 0x82d080223906 <+6>: push %r14 0x82d080223908 <+8>: push %r13 0x82d08022390a <+10>:push %r12 0x82d08022390c <+12>:push %rbx 0x82d08022390d <+13>:sub$0x28,%rsp 0x82d080223911 <+17>:mov%rsi,%r15 0x82d080223914 <+20>:mov%rdi,%rbx 0x82d080223917 <+23>:movabs $0x7d20,%r12 0x82d080223921 <+33>:lea0x267d08(%rip),%r14# 0x82d08048b630 0x82d080223928 <+40>:mov%r14,%rdi 0x82d08022392b <+43>:callq 0x82d08023a4c0 <_spin_lock> 0x82d080223930 <+48>:mov%rbx,-0x40(%rbp) 0x82d080223934 <+52>:lea(%rbx,%r12,1),%rdi 0x82d080223938 <+56>:sar$0x5,%rdi 0x82d08022393c <+60>:callq 0x82d0802249c0 0x82d080223941 <+65>:mov%rax,%rdi 0x82d080223944 <+68>:callq 0x82d080222340 <_mfn> 0x82d080223949 <+73>:mov0x267cd8(%rip),%rsi# 0x82d08048b628 0x82d080223950 <+80>:mov%rax,%rdi 0x82d080223953 <+83>:callq 0x82d080222310 0x82d080223958 <+88>:mov%rax,0x267cc9(%rip)# 0x82d08048b628 0x82d08022395f <+95>:mov%r14,%rdi 0x82d080223962 <+98>:callq 0x82d08023a530 <_spin_unlock> 0x82d080223967 <+103>: cmpl $0x3,0x37b032(%rip)# 0x82d08059e9a0 0x82d08022396e <+110>: setb -0x29(%rbp) 0x82d080223972 <+114>: cmpl $0x2,0x228a8b(%rip)# 0x82d08044c404 0x82d080223979 <+121>: sete %al 0x82d08022397c <+124>: mov%r15,-0x38(%rbp) 0x82d080223980 <+128>: test %r15,%r15 0x82d080223983 <+131>: je 0x82d080223aee 0x82d080223989 <+137>: and%al,-0x29(%rbp) 0x82d08022398c <+140>: xor%r12d,%r12d 0x82d08022398f <+143>: jmpq 0x82d080223a70 0x82d080223994 <+148>: mov-0x38(%rbp),%rax 0x82d080223998 <+152>: shl$0x5,%rax 0x82d08022399c <+156>: add-0x40(%rbp),%rax 0x82d0802239a0 <+160>: movabs $0x7d20,%rcx 0x82d0802239aa <+170>: lea(%rcx,%rax,1),%rdi 0x82d0802239ae <+174>: add$0xffe0,%rdi 0x82d0802239b2 <+178>: sar$0x5,%rdi 0x82d0802239b6 <+182>: callq 0x82d0802249c0 0x82d0802239bb <+187>: mov%rax,%rdi 0x82d0802239be <+
[llvm-bugs] [Bug 39391] Regression(r342175): ran out of registers during register allocation
https://bugs.llvm.org/show_bug.cgi?id=39391 Nirav Dave changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Nirav Dave --- It's still possible for the register allocator to get an input that causes it to run out of registers, but this particular case is 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10075 in oss-fuzz: llvm/clang-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E
Updates: Labels: Deadline-Approaching Comment #2 on issue 10075 by sheriff...@chromium.org: llvm/clang-fuzzer: ASSERT: !KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) && "E https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10075#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39706] New: clang-format gets confused when enum values comma separators are preceded with comments
https://bugs.llvm.org/show_bug.cgi?id=39706 Bug ID: 39706 Summary: clang-format gets confused when enum values comma separators are preceded with comments Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: Formatter Assignee: unassignedclangb...@nondot.org Reporter: eh...@mozilla.com CC: djas...@google.com, kli...@google.com, llvm-bugs@lists.llvm.org See the test case below: $ cat test.cpp enum foo { x // comment , y // comment , z // comment }; $ clang-format -style=Google test.cpp enum foo { x // comment , y // comment , z // comment }; -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 38391] __llvm_retpoline_r11 has machine verifier errors
https://bugs.llvm.org/show_bug.cgi?id=38391 Francis Visoiu Mistrih changed: What|Removed |Added Resolution|--- |FIXED Fixed By Commit(s)||r345426 Status|NEW |RESOLVED --- Comment #3 from Francis Visoiu Mistrih --- You're right, this is 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 32146] Enable -verify-machineinstrs with EXPENSIVE_CHECKS
https://bugs.llvm.org/show_bug.cgi?id=32146 Bug 32146 depends on bug 38391, which changed state. Bug 38391 Summary: __llvm_retpoline_r11 has machine verifier errors https://bugs.llvm.org/show_bug.cgi?id=38391 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 27481] X86 make check has a bunch of machine verifier errors
https://bugs.llvm.org/show_bug.cgi?id=27481 Bug 27481 depends on bug 38391, which changed state. Bug 38391 Summary: __llvm_retpoline_r11 has machine verifier errors https://bugs.llvm.org/show_bug.cgi?id=38391 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 7742 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #6 on issue 7742 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7742#c6 ClusterFuzz testcase 4837581448544256 is verified as fixed, so closing issue as verified. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment. ___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 7742 in oss-fuzz: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart
Comment #5 on issue 7742 by ClusterFuzz-External: llvm/llvm-isel-fuzzer--wasm32-O2: Null-dereference READ in llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7742#c5 ClusterFuzz has detected this issue as fixed in range 201811180234:201811190234. Detailed report: https://oss-fuzz.com/testcase?key=4837581448544256 Project: llvm Fuzzer: libFuzzer_llvm_llvm-isel-fuzzer--wasm32-O2 Fuzz target binary: llvm-isel-fuzzer--wasm32-O2 Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: Null-dereference READ Crash Address: 0x Crash State: llvm::WebAssemblyAsmPrinter::EmitFunctionBodyStart llvm::AsmPrinter::EmitFunctionBody llvm::WebAssemblyAsmPrinter::runOnMachineFunction Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201804120529:201804130530 Fixed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201811180234:201811190234 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4837581448544256 See https://github.com/google/oss-fuzz/blob/master/docs/reproducing.md for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page. -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 10250 in oss-fuzz: llvm: Build failure
Comment #14 on issue 10250 by ClusterFuzz-External: llvm: Build failure https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10250#c14 Friendly reminder that the the build is still failing. Please try to fix this failure to ensure that fuzzing remains productive. Latest build log: https://oss-fuzz-build-logs.storage.googleapis.com/log-c17007a9-1b09-4ea1-9a9f-55102fbf05ae.txt -- 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 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39705] New: Multiline doc comments in enums are copied to following variants
https://bugs.llvm.org/show_bug.cgi?id=39705 Bug ID: 39705 Summary: Multiline doc comments in enums are copied to following variants Product: clang Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: emi...@crisal.io CC: kli...@google.com, llvm-bugs@lists.llvm.org, richard-l...@metafoo.co.uk For the following file: enum Test { /** * hello world */ A, B, C, } All the cursors for the enum variants have the same doc comment, which seems wrong. This causes https://github.com/rust-lang-nursery/rust-bindgen/issues/1442. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 39704] New: Clang 7.0 claiming unaligned load with POWER7 vec_xl
https://bugs.llvm.org/show_bug.cgi?id=39704 Bug ID: 39704 Summary: Clang 7.0 claiming unaligned load with POWER7 vec_xl Product: compiler-rt Version: 7.0 Hardware: Other OS: other Status: NEW Severity: normal Priority: P Component: ubsan Assignee: unassignedb...@nondot.org Reporter: noloa...@gmail.com CC: llvm-bugs@lists.llvm.org I don't have a reduced case for this at the moment. We are trying to track down the cause of several failed self tests. But I hope someone can take a quick look and tweak an attribute somewhere. I'm working on GCC112, which is powerpc64le-unknown-linux-gnu. I built Clang from the 7.0 release tarballs. During a run of UBsan I caught several findings like shown below. All the findings pointed to altivec.h:16363. /home/noloader/llvm/lib/clang/7.0.0/include/altivec.h:16363:10: runtime error: load of misaligned address 0x3fffd3453848 for type '__vector unsigned char' (vector of 16 'unsigned char' values), which requires 16 byte alignment 0x3fffd3453848: note: pointer points here 00 00 00 00 a0 10 97 5f 2f e6 c9 b9 69 36 ab 5d 96 9e 6c cf fc c7 e9 ac c0 09 cd f3 aa cf 66 7c ^ altivec.h:16363 is shown below. Notice the vec_xl: 16361 static inline __ATTRS_o_ai vector unsigned char 16362 vec_xl(signed long long __offset, unsigned char *__ptr) { 16363return *(vector unsigned char *)(__ptr + __offset); 16364 } As far as I know there is no alignment requirement for the instruction. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs