Upgrading to G++ 4.8 - exception_ptr.h Does not support exception propagation

Question

I\'m trying to recompile a huge legacy app with g++ 4.8 in order debug a glibc detected memory corruption problem (using AddressSanitizer). Previously we used g++

Answer 1

I was able to reproduce your issue using dockerized Centos6, with gcc 4.8.2. After upgrading dev tools to version 6 (gcc 6.3.1), your code compiled without any problem. Try upgrading dev tools using these steps (suggested for testing only):

• add sclo centos6 repository via adding file /etc/yum.repos.d/devtools-sclo.repo :

  [testing-devtools]
  name=devtools multiple for CentOS 
  baseurl=http://mirror.centos.org/centos/6/sclo/x86_64/rh/
  gpgcheck=0
  

• install devtoolset-6 packages:

  yum install devtoolset-6-binutils devtoolset-6-gcc-c++

• set bash environment to new version:

  scl enable devtoolset-6 bash

Now try recompiling your base example and full source.

NOTE: This same repository contains packages for devtoolset-3 and devtoolset-4 also. Very easy to try if ever needed.

Answer 2

First of all, including <bits/exception_ptr.h> directly is technically unsupported. It says so right in the header file. This worked in GCC 4.4 by more or less by accident. The C++11 migration of this header file broke it because for namespace reasons, C++98 code cannot use the ATOMIC_INT_LOCK_FREE macro, and the header does not work anymore.

In GCC 7, this was fixed (again accidentally) as part of this bug:

• std::future broken on armel

The trick to include <bits/exception_ptr.h> directly should work again in this version.

This means that your options are:

1. Compile your code in C++11 or later mode (C++14 with GCC 6 recommended).
2. Upgrade to DTS 7 with GCC 7 if and when it becomes available, which has the upstream fix which re-enables the C++98 hack.
3. Wrap the use of std::exception_ptr in an opaque type, compile its implementation in C++11 or later mode, and keep the rest of the system in C++98 mode.

4. Use another hack, perhaps like this one:

   #include <exception>
   #ifndef ATOMIC_INT_LOCK_FREE
   # define ATOMIC_INT_LOCK_FREE __GCC_ATOMIC_INT_LOCK_FREE
   #endif
   #include <bits/exception_ptr.h>
   

   Again, this is completely unsupported, but it should not be any worse than what you have today (with GCC 4.4).