Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

[Jonathan Wakely <jwakely at redhat dot com>]

On 22/09/16 20:22 +0200, Christophe Lyon wrote:
> On 22 September 2016 at 15:25, Jonathan Wakely <jwakely@redhat.com> wrote:
> > On 22/09/16 12:15 +0100, Jonathan Wakely wrote:
> > > On 22/09/16 11:16 +0100, Jonathan Wakely wrote:
> > > > (Somebody should fix PR58938 so exception_ptr is portable).
> > >
> > >
> > > Christophe, would you be able to test this patch?
> > >
> > > It uses a single global mutex for exception_ptr objects, which doesn't
> > > scale well but that probably isn't a problem for processors without
> > > lock-free atomics for single words.
> > >
> > > This also solves the problem of mismatched -march options, where the
> > > header is compiled for a CPU that supports the atomics but
> > > libstdc++.so was built for an older CPU that doesn't support them, and
> > > linking fails (as in https://gcc.gnu.org/PR58938#c13).
> >
> >
> > We'd also need something like this extra piece, to ensure we don't
> > leak exceptions. Currently __gxx_exception_cleanup assumes that if
> > ATOMIC_INT_LOCK_FREE < 2 the referenceCount can never be greater than
> > 1, because there are not exception_ptr objects that could increase it.
> >
> > If we enable exception_ptr unconditionally then that assumption
> > doesn't hold. This patch uses the exception_ptr code to do the
> > cleanup, under the same mutex as any other increments and decrements
> > of the reference count.
> >
> > It's a bit of a hack though.
> Should I have applied this one on top of the other?
>
> I ran a validation with it alone, and
> arm-none-eabi with default mode, cpu, and fpu does not build:

That's expected, the second patch requires the first one (you can't
use exception_ptr unconditionally if it's only defined conditionally
:-)


> In file included from
> /tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_throw.cc:27:0:
> /tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/exception_ptr.h:43:4:
> error: #error This platform does
> not support exception propagation.
> #  error This platform does not support exception propagation.
>    ^~~~~
> make[4]: *** [eh_throw.lo] Error 1
>
>
> In addition, on arm-none-eabi --with-mode=thumb --with-cpu=cortex-a9,
> I've noticed a regression in c++
>  - PASS now FAIL             [PASS => FAIL]:
>
>  g++.dg/opt/pr36449.C  -std=gnu++11 execution test
>  g++.dg/opt/pr36449.C  -std=gnu++14 execution test
>  g++.dg/opt/pr36449.C  -std=gnu++98 execution test
>
> My logs show:
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Strange, I don't see how my patch could cause that.


> The validation of the other patch is still running: I had to re-run it
> because the
> patch didn't apply because of the ChangeLog entry.