r207471 submitted against devel/powerpc64-gcc for _Unwind_RaiseException's internal unbounded looping; matching up with 207359 against base system

> #include > > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} // same result without & > return 0; > } compiled under devel/powerpc64-gcc (gcc 5.3 based) on a FreeBSD projects/clang380-import (-r295902, for example) that was also built

Re: projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling

[In part: My references to libc++ should have been to libcxxrt. Also: devel/powerpc64-gcc produced the incomplete .eh_frame information.] On 2016-Feb-24, at 5:07 PM, Mark Millard wrote: > > [Deliberate top posting an history removal for significant new information.] > >

Re: projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling

[Deliberate top posting an history removal for significant new information.] I've finally traced the low level details of the powerpc64 _Unwind_RaiseException stuck looping failure. What I've submitted into the defect is basically that for clang 3.8.0's .eh_frame information generation in

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #10 from fernando.apesteg...@gmail.com --- (In reply to Raphael Kubo da Costa from comment #9) I think it is not doing the right thing. Have a look at this[1]. std::array is a feature introduced in C++11 and the software is not

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #9 from Raphael Kubo da Costa --- I agree, but this is legacy software (version 3 doesn't even have its own array implementation anymore as far as I can see) that won't be changed upstream. My question is

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 --- Comment #8 from Dimitry Andric --- I think the program should not try to use both "using namespace std", and then use a reserved C++11 name. It should either drop the "using namespace std", or rename its own array to

Re: clang -pg, libm and the _end symbol

Konstantin Belousov writes: > On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote: >> On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: >> > >> > I'm reviewing an update to the textproc/miller port in bug 207194, and >> > noticed it does

[Bug 207253] cad/openvsp: Fix in 11-CURRENT

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207253 Raphael Kubo da Costa changed: What|Removed |Added CC|

Re: clang -pg, libm and the _end symbol

On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote: > On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: > > > > I'm reviewing an update to the textproc/miller port in bug 207194, and > > noticed it does some ugly things in post-configure to seemingly > > work

Re: clang -pg, libm and the _end symbol

On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: > > I'm reviewing an update to the textproc/miller port in bug 207194, and > noticed it does some ugly things in post-configure to seemingly > work around the following problem (on 11-HEAD at least): > > % echo 'int

Re: clang -pg, libm and the _end symbol

On Wed, Feb 24, 2016 at 12:27:03PM +0100, Raphael Kubo da Costa wrote: > I'm reviewing an update to the textproc/miller port in bug 207194, and > noticed it does some ugly things in post-configure to seemingly > work around the following problem (on 11-HEAD at least): > > % echo 'int main(void)

clang -pg, libm and the _end symbol

I'm reviewing an update to the textproc/miller port in bug 207194, and noticed it does some ugly things in post-configure to seemingly work around the following problem (on 11-HEAD at least): % echo 'int main(void) { return 0; }' > foo.c % clang -pg foo.c -lm /usr/bin/ld: undefined reference