Hi Jonathan,
On 23 September 2016 at 12:41, Jonathan Wakely <jwak...@redhat.com> wrote: > On 22/09/16 20:22 +0200, Christophe Lyon wrote: >> >> On 22 September 2016 at 15:25, Jonathan Wakely <jwak...@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. > I've run validations with the 2 patches applied, and you can see the results here: http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/240339-pr58938-v3/report-build-info.html As you can see there are several regressions, including: 18_support/exception_ptr/40296.cc (test for excess errors) /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc: In function 'bool test01()': /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:25: error: 'exception_ptr' is not a member of 'std' /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:25: note: suggested alternative: 'fexcept_t' /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:27: error: 'p' was not declared in this scope when compiling with -march=armv5t on arm*linux* targets. On arm-none-eabi, I still see the regressions I reported when gcc is configured --with-mode=thumb --with-cpu=cortex-a9 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 I have no detail besides qemu: uncaught target signal 11 (Segmentation fault) - core dumped Finally, on arm-none-eabi using default mode/cpu, some tests no longer compile because: /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_ptr.o): In function `__gx x_dependent_exception_cleanup': /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:241: undefined reference to `__atomic_fetch_sub_4' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_ptr.o): In function `eh_p tr_mutex': /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39: undefined reference to `__sync_synchronize' /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39: undefined reference to `__sync_synchronize' /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39: undefined reference to `__sync_synchronize' /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39: undefined reference to `__sync_synchronize' /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39: undefined reference to `__sync_synchronize' /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_ptr.o):/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39: more undefined references to `__sync_synchronize' follow /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_ptr.o): In function `std::rethrow_exception(std::__exception_ptr::exception_ptr)': /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:260: undefined reference to `__atomic_fetch_add_4' collect2: error: ld returned 1 exit status FAIL: g++.dg/abi/arm_cxa_vec1.C -std=c++98 (test for excess errors) Does this help? Hopefully the above link will be easy enough for you to access to the information you need. It's available for the next 2 months. Thanks, Christophe > > >> 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.
