[llvm-bugs] [Bug 26543] Assertion failed: (DD && "queried property of class with no definition") .. DeclCXX.h, line 592
https://llvm.org/bugs/show_bug.cgi?id=26543 Alexey Bataev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Alexey Bataev --- Fixed in r260370 -- 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 25786] Assertion "Chunk.Kind == DeclaratorChunk::Function" failed with regparm attribute
https://llvm.org/bugs/show_bug.cgi?id=25786 Alexander Makarov changed: What|Removed |Added Status|ASSIGNED|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 26559] New: Crash on converting int128 to float
https://llvm.org/bugs/show_bug.cgi?id=26559
Bug ID: 26559
Summary: Crash on converting int128 to float
Product: libraries
Version: trunk
Hardware: Other
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: SystemZ
Assignee: unassignedb...@nondot.org
Reporter: koria...@0x04.net
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
$ cat bug.c
typedef unsigned tu_int __attribute__ ((mode (TI)));
tu_int a = 1;
float b;
int main() {
b = a;
return 0;
}
$ clang bug.c -O3
$ ./a.out
Segmentation fault (core dumped)
(-O3 is not necessary, but simplifies the emitted assembly)
This is a backend bug - clang simply emits a uitofp:
; Function Attrs: norecurse nounwind
define signext i32 @main() #0 {
entry:
%0 = load i128, i128* @a, align 16, !tbaa !1
%conv = uitofp i128 %0 to float
store float %conv, float* @b, align 4, !tbaa !5
ret i32 0
}
It seems __floatuntis is incorrectly called with the argument in %r2:%r3, when
it should be called with pointer to argument in %r2:
main: # @main
# BB#0: # %entry
stmg%r14, %r15, 112(%r15)
aghi%r15, -160
lgrl%r2, a
lgrl%r3, a+8
brasl %r14, __floatuntisf@PLT
larl%r1, b
ste %f0, 0(%r1)
lghi%r2, 0
lmg %r14, %r15, 272(%r15)
br %r14
gcc gets that right:
main:
.LFB0:
.cfi_startproc
stmg%r14,%r15,112(%r15)
larl%r1,a
lmg %r4,%r5,0(%r1)
.cfi_offset 14, -48
.cfi_offset 15, -40
lay %r15,-176(%r15)
.cfi_def_cfa_offset 336
la %r2,160(%r15)
stmg%r4,%r5,160(%r15)
brasl %r14,__floatuntisf
lghi%r2,0
larl%r5,b
lmg %r14,%r15,288(%r15)
.cfi_restore 15
.cfi_restore 14
.cfi_def_cfa_offset 160
ste %f0,0(%r5)
br %r14
.cfi_endproc
Found when attempting to port UBSan to SystemZ
(compiler-rt/test/ubsan/TestCases/Float/cast-overflow.cpp triggers it).
--
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 26560] New: FAIL: Profile :: Linux/coverage_ctors.cpp
https://llvm.org/bugs/show_bug.cgi?id=26560 Bug ID: 26560 Summary: FAIL: Profile :: Linux/coverage_ctors.cpp Product: new-bugs Version: trunk Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: hjl.to...@gmail.com CC: davi...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified On Linux/x86, I got FAIL: Profile :: Linux/coverage_dtor.cpp (25980 of 26369) FAIL: Profile :: Linux/coverage_ctors.cpp (25981 of 26369) FAIL: Profile :: Linux/coverage_test.cpp (25983 of 26369) Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. FAIL: Profile :: Linux/coverage_dtor.cpp (25980 of 26369) TEST 'Profile :: Linux/coverage_dtor.cpp' FAILED Script: -- /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/./bin/clang -ldl -x c++ -fno-exceptions -std=c++11 -fuse-ld=gold -fprofile-instr-generate -fcoverage-mapping -o /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_dtor.cpp.tmp /export/gnu/import/git/llvm/projects/compiler-rt/test/profile/Linux/coverage_dtor.cpp env LLVM_PROFILE_FILE=/export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_dtor.cpp.tmp.profraw /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_dtor.cpp.tmp llvm-profdata merge -o /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_dtor.cpp.tmp.profdata /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_dtor.cpp.tmp.profraw llvm-cov show /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_dtor.cpp.tmp -instr-profile /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_dtor.cpp.tmp.profdata -filename-equivalence 2>&1 | FileCheck /export/gnu/import/git/llvm/projects/compiler-rt/test/profile/Linux/coverage_dtor.cpp -- Exit Code: 1 Command Output (stderr): -- /export/gnu/import/git/llvm/projects/compiler-rt/test/profile/Linux/coverage_dtor.cpp:24:22: error: expected string not found in input return 1; // CHECK: 0| [[@LINE]]| return 1; ^ :17:31: note: scanning from here 2| 15| ~Derived() = default; // CHECK: 2| [[@LINE]]| ~Derived() = default; ^ :17:31: note: with expression "@LINE" equal to "24" 2| 15| ~Derived() = default; // CHECK: 2| [[@LINE]]| ~Derived() = default; ^ :26:2: note: possible intended match here | 24| return 1; // CHECK: 0| [[@LINE]]| return 1; ^ -- Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. FAIL: Profile :: Linux/coverage_ctors.cpp (25981 of 26369) TEST 'Profile :: Linux/coverage_ctors.cpp' FAILED Script: -- /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/./bin/clang -ldl -fprofile-instr-generate -x c++ -std=c++11 -fuse-ld=gold -fcoverage-mapping -o /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_ctors.cpp.tmp /export/gnu/import/git/llvm/projects/compiler-rt/test/profile/Linux/coverage_ctors.cpp env LLVM_PROFILE_FILE=/export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_ctors.cpp.tmp.profraw /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_ctors.cpp.tmp llvm-profdata merge -o /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_ctors.cpp.tmp.profdata /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_ctors.cpp.tmp.profraw llvm-cov show /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_ctors.cpp.tmp -instr-profile /export/build/gnu/llvm-clang-x86-bootstrap/stage1/build-i686-linux/projects/compiler-rt/test/profile/Linux/Output/coverage_ctors.cpp.tmp.profdata -filename-equivalence 2>&1 | FileCheck /export/gnu/import/git/llvm/projects/compiler-rt/test/profile/Linux/coverage_ctors.cpp -- Exit Code: 1 Command Output (stderr): -- /export/gnu/import/git/llvm/projects/compiler-rt/test/profile/Linux/coverage_ctors.cpp:18:48: error: expected string not found in input Derived(const Derived &) = default; // CHECK: 2| [[@LINE]]|
[llvm-bugs] [Bug 26561] New: spec2000/188.ammp miscompare fail on IA64 HSW architecture after commit r260063
https://llvm.org/bugs/show_bug.cgi?id=26561 Bug ID: 26561 Summary: spec2000/188.ammp miscompare fail on IA64 HSW architecture after commit r260063 Product: libraries Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: Backend: X86 Assignee: unassignedb...@nondot.org Reporter: sergey.k.oku...@gmail.com CC: llvm-bugs@lists.llvm.org, llvm-...@redking.me.uk, sergey.k.oku...@gmail.com, sergos@gmail.com, spatel+l...@rotateright.com, zia.ans...@intel.com Classification: Unclassified Bisect analysis showed LLVM revision 260063 is responsible for the fail. The comments to commit are the following. commit 392b9d21fce095df29f5a549c4a7d9d59761b32f Author: Simon Pilgrim Date: Sun Feb 7 22:51:06 2016 + [X86][SSE] Resolve target shuffle inputs to sentinels to permit more combines The combineX86ShufflesRecursively only supports unary shuffles, but was missing the opportunity to combine binary shuffles with a zero / undef second input. This patch resolves target shuffle inputs, converting the shuffle mask elements to SM_SentinelUndef/SM_SentinelZero where possible. It then resolves the updated mask to check if we have created a faux unary shuffle. Additionally, we now attempt to recursively call combineX86ShufflesRecursively for all input operands (we used to just recurse for unary integer shuffles and unary unpacks) - it safely returns early if its not a target shuffle. Differential Revision: http://reviews.llvm.org/D16683 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260063 91177308-0d34-0410-b5e6-96231b3b80d8 LLVM-clang options: -m64 -fuse-ld=gold -static -O2 -ffast-math -march=core-avx2 The failure is reproduced in concurrent applying of “-ffast-math -march=core-avx2” options only. spec2000 harness gives the following miscompare message (file – ammp.out.cmp). 0012: 1183.095771 bond energy 1036.076023 bond energy ^ 0013: 2140.779933 angle energy 2049.475812 angle energy ^ 0014: 67.674876 hybrid energy 63.753323 hybrid energy ^ 0016: -15738.937252 non-bonded energy -14111.964160 non-bonded energy ^ 0017: -11819.178977 total potential energy -10434.282631 total potential energy ^ 0018: 8533.288451 total kinetic energy 8588.981709 total kinetic energy ^ 0019: -3285.890527 total energy -1845.300921 total energy ^ 0020: 20352.467428 total action 19023.264340 total action ^ 0025: 1232.045367 bond energy 1061.815654 bond energy ^ 0026: 2228.827988 angle energy 2053.136001 angle energy ^ 0027: 69.507047 hybrid energy 65.092695 hybrid energy Okunev Sergey, Software Engineer Intel Compiler Team -- 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 26562] New: libc++abi doesn't make __cxa_exception public
https://llvm.org/bugs/show_bug.cgi?id=26562 Bug ID: 26562 Summary: libc++abi doesn't make __cxa_exception public Product: libc++abi Version: 3.8 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: unassignedb...@nondot.org Reporter: kre...@email.com CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com Classification: Unclassified libcxxrt and libstdc++ do export the symbol and definition, but not libc++abi. This leads to build failure when building libreoffice, which itself uses __cxa_exception directly (don't ask, I have no idea why). Linux x86_64, llvm/clang/libc++/libc++abi 3.8.0rc1. -- 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 26564] New: Performance regression in AA
https://llvm.org/bugs/show_bug.cgi?id=26564 Bug ID: 26564 Summary: Performance regression in AA Product: new-bugs Version: 3.8 Hardware: PC OS: Linux Status: NEW Keywords: performance Severity: normal Priority: P Component: new bugs Assignee: unassignedb...@nondot.org Reporter: bstei...@gmail.com CC: chandl...@gmail.com, llvm-bugs@lists.llvm.org Classification: Unclassified Since upgrading to a more recent LLVM version for the Rust compiler, there has been a large increase in compile time spent in LLVM optimizations. The corresponding Rust bug report can be found here: https://github.com/rust-lang/rust/issues/31435 At least part of that seems to come from the new AA handling, which exhibits O(n^2) behavior in some cases with n being the number of active AA passes. This originates from using the AAResultProxy in the AAResultBase class. For example, calling AAResults::getModRefBehavior(CallSite) will iterate over all registered AA results which all may eventually call into AAResultBase::getModRefBehavior(CallSite) which calls AAResultProxy::getModRefBehavior(Function*) which will then iterate over all registered passes again. -- 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 26560] FAIL: Profile :: Linux/coverage_ctors.cpp
https://llvm.org/bugs/show_bug.cgi?id=26560 David (Xinliang) Li changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from David (Xinliang) Li --- Fixed in r260394 -- 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 26506] clang-cl -fmsc-version=1900 produces .obj files that don't link
https://llvm.org/bugs/show_bug.cgi?id=26506 David Majnemer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassignedclangbugs@nondot. |david.majne...@gmail.com |org | --- Comment #7 from David Majnemer --- I've implemented the better fix in r260388. -- 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 26565] New: test_expr_with_macros_dwarf (TestMacros.TestMacros) failing on FreeBSD 11
https://llvm.org/bugs/show_bug.cgi?id=26565 Bug ID: 26565 Summary: test_expr_with_macros_dwarf (TestMacros.TestMacros) failing on FreeBSD 11 Product: lldb Version: unspecified Hardware: PC OS: FreeBSD Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: ema...@freebsd.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified Command invoked: /usr/home/user/llvm/tools/lldb/test/dotest.py -q --arch=x86_64 --executable /usr/home/user/llvm/build/bin/lldb -s /usr/home/user/llvm/build/lldb-test-traces -u CXXFLAGS -u CFLAGS -C /usr/bin/cc --results-port 52272 --inferior -p TestMacros.py /usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test --event-add-entries worker_index=2:int FAIL: LLDB (/usr/bin/cc-x86_64) :: test_expr_with_macros_dwarf (TestMacros.TestMacros) == FAIL: test_expr_with_macros_dwarf (TestMacros.TestMacros) -- Traceback (most recent call last): File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1452, in dwarf_test_method return attrvalue(self) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py", line 92, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py", line 92, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py", line 92, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/expression_command/macros/TestMacros.py", line 50, in test_expr_with_macros self.assertTrue(result.IsValid() and result.GetValue() == "100", "MACRO_1 = 100") AssertionError: False is not True : MACRO_1 = 100 Config=x86_64-/usr/bin/cc -- Ran 1 test in 0.248s Found while getting the tests running again on the FreeBSD buildbot; system compiler is "FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257) 20150906" This test does not fail for me on my desktop running a FreeBSD 10.x snapshot (around FreeBSD 10.3); system compiler is "FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512". -- 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 26566] New: test_with_run_command_dwarf (TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase) failing on FreeBS 11
https://llvm.org/bugs/show_bug.cgi?id=26566
Bug ID: 26566
Summary: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatt
erTestCase) failing on FreeBS 11
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-...@lists.llvm.org
Reporter: ema...@freebsd.org
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Command invoked: /usr/home/user/llvm/tools/lldb/test/dotest.py -q --arch=x86_64
--executable /usr/home/user/llvm/build/bin/lldb -s
/usr/home/user/llvm/build/lldb-test-traces -u CXXFLAGS -u CFLAGS -C /usr/bin/cc
--results-port 52272 --inferior -p TestDataFormatterLibcxxListLoop.py
/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=3:int
FAIL: LLDB (/usr/bin/cc-x86_64) :: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase)
==
FAIL: test_with_run_command_dwarf
(TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase)
--
Traceback (most recent call last):
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1452, in dwarf_test_method
return attrvalue(self)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/decorators.py",
line 121, in wrapper
func(*args, **kwargs)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/TestDataFormatterLibcxxListLoop.py",
line 42, in test_with_run_command
self.expect("frame variable *numbers_list", substrs=['[0] = 1', '[1] = 2',
'[2] = 3', '[3] = 4', '[5] = 6'])
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 1904, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : '[0] = 1' returns expected result
Config=x86_64-/usr/bin/cc
Found while getting the tests running again on the FreeBSD buildbot; system
compiler is "FreeBSD clang version 3.7.0 (tags/RELEASE_370/final 246257)
20150906"
This test does not fail for me on my desktop running a FreeBSD 10.x snapshot
(around FreeBSD 10.3); system compiler is "FreeBSD clang version 3.4.1
(tags/RELEASE_34/dot1-final 208032) 20140512".
--
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 23748] Tag lookup should not find hidden declarations
https://llvm.org/bugs/show_bug.cgi?id=23748 Vassil Vassilev changed: What|Removed |Added Status|NEW |RESOLVED CC||vvasi...@cern.ch Resolution|--- |FIXED --- Comment #1 from Vassil Vassilev --- I cannot reproduce this anymore. I believe it was fixed in r252960. -- 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 26512] Repeatable Compiler crash on v3.7.1
https://llvm.org/bugs/show_bug.cgi?id=26512
Reid Kleckner changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE |---
--- Comment #3 from Reid Kleckner ---
This appears to be different. It has to do with dependent types sneaking
through to codegen via templated friend functions (ew). Here's what I got from
reduction:
struct A {
template class B {
template
friend void advance(B &,
distance_type);
};
template
friend void advance(B &, distance_type)
{
distance_type a;
}
};
int main() {
A::B b;
advance(b, 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 26567] New: Backtrace missing frames while debugging breakpad generated minidump
https://llvm.org/bugs/show_bug.cgi?id=26567 Bug ID: 26567 Summary: Backtrace missing frames while debugging breakpad generated minidump Product: lldb Version: unspecified Hardware: PC OS: other Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-...@lists.llvm.org Reporter: joshual...@google.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified I am trying out the minidump target on the windows lldb builds. My test was to debug a windows minidump generated through breakpad using lldb/trunk@259885 I've attached: The executable with debug symbols (cross compiled from linux with mingw-gcc). This was used to generate the breakpad symbols. The minidump generated through breakpad The stack trace that I get from lldb Using breakpad's stackwalk tool I see the following stack trace (truncated) which has the correct stack trace. Report ID859ac030 Total Threads43 Processed Threads43 Thread 1 CRASHED [EXCEPTION_ACCESS_VIOLATION_READ @ 0x ] 0x005c1f13(emulator-x86.exe -console.c:2606 )do_crash 0x005be45b(emulator-x86.exe -console.c:427 )control_client_do_command 0x005be713(emulator-x86.exe -console.c:513 )control_client_read_byte 0x005bea56(emulator-x86.exe -console.c:572 )control_client_read 0x00459d65(emulator-x86.exe -Looper.cpp:129 ) android::qemuQemuLooper::FdWatch::fire 0x0045aac0(emulator-x86.exe -Looper.cpp:329 ) android::qemuQemuLooper::handleBottomHalf 0x00408942(emulator-x86.exe -async.c:150 )qemu_bh_poll 0x004a2f3a(emulator-x86.exe -main-loop.c:307 )main_loop_wait 0x004a2f83(emulator-x86.exe -main-loop.c:333 )main_loop 0x004bd73a(emulator-x86.exe -vl-android.c:3853 )qemu_main 0x0045c0e6(emulator-x86.exe -main.c:155 )enter_qemu_main_loop 0x007fb32d(emulator-x86.exe -emulator-qt-window.h:64 ) MainLoopThread::run 0x6696291d(Qt5Core.dll + 0x0002291d ) 0x76e67faf(msvcrt.dll + 0x00017faf ) 0x76e680f4(msvcrt.dll + 0x000180f4 ) 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) Thread 0 0x778dc9ec(ntdll.dll + 0x0003c9ec ) 0x7550dcc2(user32.dll + 0xdcc2 ) 0x66b6d1af(Qt5Core.dll + 0x0022d1af ) 0x6dee4580(qwindows.dll + 0x00024580 ) 0x66b164a5(Qt5Core.dll + 0x001d64a5 ) 0x66b1e467(Qt5Core.dll + 0x001de467 ) 0x0053d116(emulator-x86.exe -winsys-qt.cpp:115 ) skin_winsys_enter_main_loop 0x0045e4e5(emulator-x86.exe -main.c:1030 )qt_main 0x0053e997(emulator-x86.exe -winsys-qt.cpp:397 )qMain 0x00402801(emulator-x86.exe -qtmain_win.cpp:113 )WinMain 0x0089f3ec(emulator-x86.exe -crt0_c.c:18 )main 0x00401401(emulator-x86.exe -crtexe.c:315 )__tmainCRTStartup 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) Thread 2 0x778dc47c(ntdll.dll + 0x0003c47c ) 0x77222c01(KERNELBASE.dll + 0x2c01 ) 0x005e7637(emulator-x86.exe -ConditionVariable_win32.cpp:91 ) android::base::ConditionVariable::wait 0x005b4297(emulator-x86.exe -WearAgent.cpp:261 ) android::wear::WearAgentImpl::connectToAdbHostWorker 0x005b4a84(emulator-x86.exe + 0x001b4a84 ) 0x005b5197(emulator-x86.exe -functional:2057 ) std::_Function_handler::_M_invoke 0x00845ce9(emulator-x86.exe -functional:2471 ) std::function::operator() 0x005e19c5(emulator-x86.exe -FunctorThread.cpp:29 ) android::base::FunctorThread::main 0x005e7e0c(emulator-x86.exe -Thread_win32.cpp:127 ) android::base::Thread::thread_main 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) Thread 3 0x778dc47c(ntdll.dll + 0x0003c47c ) 0x77222c01(KERNELBASE.dll + 0x2c01 ) 0x005e7637(emulator-x86.exe -ConditionVariable_win32.cpp:91 ) android::base::ConditionVariable::wait 0x005dcfcd(emulator-x86.exe -MessageChannel.cpp:51 ) android::base::MessageChannelBase::beforeRead 0x00823812(emulator-x86.exe -MessageChannel.h:87 ) android::base::MessageChannel::receive 0x007f9f61(emulator-x86.exe -camera-capture-windows.cpp:905 ) CameraThread::main 0x005e7e0c(emulator-x86.exe -Thread_win32.cpp:127 ) android::base::Thread::thread_main 0x75677c03(kernel32.dll + 0x00017c03 ) 0x778fad6e(ntdll.dll + 0x0005ad6e ) 0x778fad39(ntdll.dll + 0x0005ad39 ) When I use lldb, I get the following backtrace which has some similar frames but some threads are basically empty. For example, Thread 2 below is Thread 1 in the above stacktrace due to start at 0 count but there are only kernel frames even though
[llvm-bugs] [Bug 26569] New: invalid linkage type for global declaration [5 x i8*]* @"\01??_S?$HeapSupplement@VPage@blink@@@blink@@6B@"
https://llvm.org/bugs/show_bug.cgi?id=26569 Bug ID: 26569 Summary: invalid linkage type for global declaration [5 x i8*]* @"\01??_S?$HeapSupplement@VPage@blink@@@blink@@6B@" Product: clang Version: trunk Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: h...@chromium.org CC: llvm-bugs@lists.llvm.org Classification: Unclassified This is using trunk Clang in a Chromium build (e.g. https://build.chromium.org/p/chromium.fyi/builders/ClangToTWin64%28dll%29/builds/5549/steps/compile/logs/stdio). Repro coming up! -- 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 26570] New: incomplete support for -fdata-sections in clang/llvm for C++ static data members
https://llvm.org/bugs/show_bug.cgi?id=26570
Bug ID: 26570
Summary: incomplete support for -fdata-sections in clang/llvm
for C++ static data members
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: th...@google.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
Created attachment 15875
--> https://llvm.org/bugs/attachment.cgi?id=15875&action=edit
test case
The attached test case and makefile illustrate a limitation in the current
clang/llvm implementation of the "-fdata-sections" command line option. This
option tells the compiler to place each named data item into a separate ELF
section in the resulting object file; doing this has benefits in that it helps
enable linker GC of unused sections and (if desired) linker reordering of
sections for performance/size reasons.
In the test case ("ex.cc") note the following two variables:
char foo::ID = 0;
char baz::ID = 0;
When you compile with -fdata-sections, these two vars are still placed into the
same ".bss" section, which effectively defeats the option.
To illustrate why this is a problem, download the testcase + makefile and run
"make doit", then diff the two files
ex.so.od.clang.txt ex.so.od.gcc.txt
For gcc (which doesn't make the same mistake), the linker is able to
garbage-collect the storage for "_ZN12_GLOBAL__N_13foo2IDE", whereas in the
LLVM case this dead storage can't be reclaimed (since the var in question is in
the same section with another variable that is not dead).
NB: there maybe other cases in which -fdata-sections also doesn't work (I
haven't done an exhaustive search). It does seem to work ok for C-style
variable declarations as far as I can tell.
--
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 26571] New: C interface should properly expose the OpenCL kernel attribute as such
https://llvm.org/bugs/show_bug.cgi?id=26571 Bug ID: 26571 Summary: C interface should properly expose the OpenCL kernel attribute as such Product: clang Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P Component: libclang Assignee: unassignedclangb...@nondot.org Reporter: giuseppe.bilo...@gmail.com CC: kli...@google.com, llvm-bugs@lists.llvm.org Classification: Unclassified Hello all, I'm trying to write a simple C program that uses libclang to parse OpenCL C files, identify kernel functions and processes them in some way. I've found however that the `kernel` attribute that identifies OpenCL kernels is not properly exposed by the C interface of libclang: the node is found as the first child of the function declaration, but it only satisfies clang_isAttribute() and clang_isUnexposed(), it does not have its own specific cursor kind (in contrast to other nodes such as . -- 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 26538] [lld] Support for __attribute__((init_priority(N)))
https://llvm.org/bugs/show_bug.cgi?id=26538 Rui Ueyama changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Rui Ueyama --- Implemented in r260460. -- 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 26572] New: [GlobalISel] Generic virtual registers have nullptr as register class
https://llvm.org/bugs/show_bug.cgi?id=26572 Bug ID: 26572 Summary: [GlobalISel] Generic virtual registers have nullptr as register class Product: libraries Version: trunk Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: GlobalISel Assignee: unassignedb...@nondot.org Reporter: qcolom...@apple.com CC: llvm-bugs@lists.llvm.org Classification: Unclassified As r260474, generic virtual registers have not a register class. We may want to change that. For instance, if we want to use all the methods from TargetRegisterInfo with generic virtual registers, we need to either have some sort of generic register classes that do what we want, or teach those methods how to deal with nullptr register class. Although the latter seems easy enough to do, we may still want to differenciate generic register classes from nullptr to catch cases where nullptr gets introduced by a bug of some sort. -- 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 26110] clang c compiler produces wrong result for the attached c code with -O2 optimzation
https://llvm.org/bugs/show_bug.cgi?id=26110
Ahmed Bougacha changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||ahmed.bouga...@gmail.com
Component|LLVM Codegen|Backend: X86
Version|3.7 |trunk
Resolution|FIXED |---
Assignee|unassignedclangbugs@nondot. |unassignedb...@nondot.org
|org |
Product|clang |libraries
--- Comment #3 from Ahmed Bougacha ---
So; I looked a little closer. Sanjay's bisect was correct. clang-700 is pretty
old now; I bisected to:
r229099 [SimplifyCFG] Be more aggressive
Sure enough, this still reproduces on trunk with -mllvm
-phi-node-folding-threshold=1.
Long story short: the problematic pattern is:
(c ? -v : v)
which we lower to (because "c" is <4 x i1>, lowered as a vector mask):
(~c & v) | (c & -v)
roughly corresponding to this IR:
define <4 x i32> @t(<4 x i32> %v, <4 x i32> %c) {
%cl = shl <4 x i32> %c,
%cs = ashr <4 x i32> %c,
%tmp2 = trunc <4 x i32> %cs to <4 x i1>
; ^ not as artificial as it looks: equivalent to a legalized vsetcc
%mv = sub nsw <4 x i32> zeroinitializer, %v
%r = select <4 x i1> %tmp2, <4 x i32> %v, <4 x i32> %mv
ret <4 x i32> %r
}
The SSE2 codegen is pretty straightforward:
xorps %xmm1, %xmm1
... # xmm6 <- %v
... # xmm3 <- %c
psubd %xmm6, %xmm1 # 0 - v# 0 - 5 -> -5
movaps %xmm3, %xmm0 # c# 0 -> 0
pandn %xmm6, %xmm0 # ~c & v # ~0 & 5 -> 5
pand %xmm3, %xmm1 # c & -v # -5 & 0 -> 0
por%xmm0, %xmm1 # (~c & v) | (c & -v) # 0 | 5 -> 5
However when we have SSSE3 (the default on OS X), we try to match it to PSIGND,
instead doing:
psignd%xmm3, %xmm1# (c < 0 ? -v : (c > 0 ? v : 0))
# c is a mask, so (c > 0) == 0
# (c ? -v : 0)
# (0 ? -5 : 0)
# -> 0
Which is not equivalent; one does:
(c ? -v : 0)
the other:
(c ? -v : v)
Now. This bug existed since 2010. However, I think we don't know about this
issue because of operand canonicalization.
The PSIGN combine matches:
(or (and m, x), (pandn m, (0 - x)))
(or (and x, m), (pandn m, (0 - x)))
(or (pandn m, (0 - x)), (and m, x))
(or (pandn m, (0 - x)), (and x, m))
but not the variants of:
(or (and m, (0 - x)), (pandn m, x))
Which is what gets generated for the function above (the most obvious IR that I
could write).
I think this is pretty easy to fix: instead of using c as a mask, put any
non-sign bit in there, to default to the 'v' case.
So, this should work:
por <1,1,1,1>, %xmm3 # c' = c | 1
psignd%xmm3, %xmm1 # (c' < 0 ? -v : (c' > 0 ? v : 0))
# c is a mask, so c' is either 1 or 0xff..f
# (c' == 0xff..f ? -v : (c' != 0 ? v : v))
# (c' == 0xff..f ? -v : v)
# (0 ? -5 : 5)
# -> 5
CP loads are cheap, so this is probably still a win over the SSE2 codegen:
psrad$31, %xmm1
pxor%xmm2, %xmm2
psubd%xmm0, %xmm2
pand%xmm1, %xmm2
pandn%xmm0, %xmm1
por%xmm1, %xmm2
movdqa%xmm2, %xmm0
Note that I don't think the couple of PSIGN tests in trunk are correct either.
Consider test/CodeGen/X86/vec-sign.ll:
define <4 x i32> @signd(<4 x i32> %a, <4 x i32> %b) nounwind {
entry:
%b.lobit = ashr <4 x i32> %b,
%sub = sub nsw <4 x i32> zeroinitializer, %a
%0 = xor <4 x i32> %b.lobit,
%1 = and <4 x i32> %a, %0
%2 = and <4 x i32> %b.lobit, %sub
%cond = or <4 x i32> %1, %2
ret <4 x i32> %cond
}
if %b is zero:
%b.lobit = <4 x i32> zeroinitializer
%sub = sub nsw <4 x i32> zeroinitializer, %a
%0 = <4 x i32>
%1 = <4 x i32> %a
%2 = <4 x i32> zeroinitializer
%cond = or <4 x i32> %1, %2
ret <4 x i32> %a
}
whereas we currently generate:
psignd %xmm1, %xmm0
retq
which return 0, as %xmm1 is 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
