Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc

[Paolo Carlini]

Hi,
>> 1- Try to re-organize the new code in order to make possible using in 
>> *few* selected places _GLIBCXX_ATOMIC_BUILTINS_4 to enable / disable 
>> the new feature completely.
> The necessary code changes for this are in the attached patch. Most of 
> the code doesn't need to be touched, because the added code doesn't 
> affect the non-exception_ptr case. The only thing that *needs* to 
> change is that the reference counting is removed from 
> __gxx_exception_cleanup. The reference count part of the 
> __cxa_exception struct can stay - it's simply unused, except for the 
> initialization in __cxa_throw.
> Of course, that additional field and the initialization can be ifdefed 
> out too, if you want.
Ok, great, seems a sane approach to me. On the positive side, we should 
also consider that each day more machines (certainly most the new ones 
in the server / desktop / notebook classes)  can use the new code.
> The necessary configuration changes:
> 1) eh_ptr.cc must be excluded from compilation completely if the 
> feature is unavailable.
> 2) The test cases must be excluded from the test runs.
Ok, I'll do this, it's rather straightforward.
> 3) It needs to be remembered whether propagation was included in the 
> build. c++config needs to define _GLIBCXX_EXCEPTION_PTR_SUPPORTED on 
> platforms where it was. The issue here is that I don't know if 
> _GLIBCXX_ATOMIC_BUILTINS_4 keeps the value it had during the GCC build 
> when client programs get compiled, and the client would get weird 
> errors if it didn't. If it does, the new macro can simply be replaced.
Yes, no problem here too. In a first approximation, we can also avoid 
_GLIBCXX_EXCEPTION_PTR_SUPPORTED and just rely on 
_GLIBCXX_ATOMIC_BUILTINS_4. But if people would find that useful, we can 
at some point add code to acinclude.m4 to define at configure time 
_GLIBCXX_EXCEPTION_PTR_SUPPORTED consistently with the outcome for 
_GLIBCXX_ATOMIC_BUILTINS_4. Actually that strategy, defining at 
configure time fine-grained macros, one for each enabled / disabled 
C++0x feature which requires some sort of support not always available, 
seems a nice one in general, let's revisit the library about that in a 
few weeks, when we'll be feature complete for 4.4.0.

Paolo.