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

[Sebastian Redl]

Paolo Carlini wrote:
> Paolo Carlini wrote:
>> I'm going to revert again the whole thing and wait for a different, 
>> safe, approach, sorry.
> In the short time frame, i.e., something solid for 4.4.0, I would 
> suggest two possible strategies:
>
> 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.

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.
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.

I don't know how to do these configuration changes, so I couldn't 
actually test my patch yet.
> 2- Learn from guard.cc. In that libsupc++ implementation file, 
> *certainly* atomic builtins are safely used, with fall-backs.
I'm afraid trying to learn something from that file is a futile exercise 
for me. It's a chaos of ifdefs that I simply don't understand. It seems 
to fall back to some global mutex for synchronization, which seems to be 
implemented entirely inline. (The mutex is part of libstdc++, so if it 
wasn't inline, you'd get the same link problems.)

Sebastian
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: switch.patch
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20080823/1e254d8c/attachment.ksh>