Date: Sun, 28 Feb 2016 00:46:22 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 207359] projects/clang380-import for TARGET_ARCH=powerpc64 via powerpc64-gcc : c++ exceptions unbounded loop in _Unwind_RaiseException (9 line program) Message-ID: <bug-207359-8-HKvzKkUffx@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-207359-8@https.bugs.freebsd.org/bugzilla/> References: <bug-207359-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207359 --- Comment #8 from Mark Millard <markmi@dsl-only.net> --- A warning relative to clang 3.8.0 and c++ exception handling and being able= to test fixes to c++ exception handling in an overall manor for clang: clang 3.8.0 for powerpc and powerpc64 messes up what __builtin_dwarf_cfa() returns and the c++ exception handling infrastructure depends on that. So until both clang 3.8.0's __builtin_dwarf_cfa() and the FreeBSD's libgcc_= s's DW_CFA_remember_state/DW_CFA_restore_state handling are fixed c++ exceptions are going to be broken to some degree. (The clang problem is always involve= d.) powerpc64's use of a stack "red zone" and late stack pointer decrementing/e= arly incrementing may make it more likely to use DW_CFA_remember_state/DW_CFA_restore_state in the .eh_frame information, especially with inlining and the llike. Currently clang 3.8.0's ABI violation for powerpc code generation puts it in the same category with powerpc64 for this since it is also using a "red zon= e". g++49 and g++5 do not have clang's __builtin_dwarf_cfa() problem for powerp= c64 or for powerpc. So for now they are better for having a more overall testin= g of library code involved in C++ exception handling. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207359-8-HKvzKkUffx>