>> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html
>
> That thread is from 2009.
>
>> it seems that the actually committed fix for the bug that the
>> gcc41-unwind-restore-state.patch was meant to fix was
>> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00617.html committed as
>> http://gcc.
> I don't remember it well, but from re-reading the gcc-patches threads around
> that time like:
> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00368.html
That thread is from 2009.
> it seems that the actually committed fix for the bug that the
> gcc41-unwind-restore-state.patch was meant to fix
On Mon, Mar 17, 2014 at 06:12:13PM +0100, Stefan Ring wrote:
> At the company where I work, we have a large program using Boost
> Python (1.54). We do our product builds for RHEL 5 and recently
> started building using gcc 4.8 from RedHat devtoolset 2 for
> performance. This works well, except for
At the company where I work, we have a large program using Boost
Python (1.54). We do our product builds for RHEL 5 and recently
started building using gcc 4.8 from RedHat devtoolset 2 for
performance. This works well, except for one system where it would
deterministically crash. I traced it to an
