From patchwork Mon Jan 30 17:54:58 2017
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Jonathan Wakely
+The GCC 7 release series differs from previous GCC releases in
+a number of ways. Some of
+these are a result of bug fixing, and some old behaviors have been
+intentionally changed in order to support new standards, or relaxed
+in standards-conforming ways to facilitate compilation or run-time
+performance. Some of these changes are not visible to the naked eye
+and will not cause problems when updating from older versions.
+
+However, some of these changes are visible, and can cause grief to
+users porting to GCC 7. This document is an effort to identify major
+issues and provide clear solutions in a quick and easily searched
+manner. Additions and suggestions for improvement are welcome.
+Porting to GCC 7
+
+Preprocessor issues
+
+
+C language issues
+
+
+C++ language issues
+
+Mangling change for conversion operators
+
+GCC 7 changes the name mangling for a conversion operator that returns a type
+using the abi_tag
attribute, see
+PR 71712.
+This affects code that has conversions to std::string
,
+for example:
+
struct A {
+ operator std::string() const;
+};
+
+
++Code using such conversions might fail to link if some objects are compiled +with GCC 7 and some are compiled with older releases. +
+ +
+Several C++ Standard Library headers have been changed to no longer include
+the <functional>
header.
+As such, C++ programs that used components defined in
+<functional>
without explicitly including that header
+will no longer compile.
+
+Previously components such as std::bind
+and std::function
were implicitly defined after including
+unrelated headers such as <memory>
,
+<futex>
, <mutex>
, and
+<regex>
.
+Correct code should #include <functional>
to define them.
+
abs
+As required by the latest C++ draft, all overloads of the abs
+function are declared by including either of
+<cstdlib>
or <cmath>
+(and correspondingly by either of <stdlib.h>
or
+<math.h>
). Previously <cmath>
only
+declared the overloads for floating-point types, and
+<cstdlib>
only declared the overloads for integral types.
+
+As a result of this change, code which overloads abs
may no longer
+compile if the custom overloads conflict with one of the additional overloads
+in the standard headers. For example, this will not compile:
+
#include <stdlib.h>
+float abs(float x) { return x < 0 ? -x : x; }
+
+The solution is to use the standard functions, not define conflicting
+overloads. For portability to previous versions of GCC and other
+implementations the abs(float)
function can be brought into
+scope by including <cmath
and adding a using-declaration:
+#include <stdlib.h>
+#include <cmath> // ensure std::abs(float) is declared
+using std::abs;
+
+
+
+
+Additionally, calling
+abs
with an argument of unsigned type is now ill-formed after
+inclusion of any standard abs
overload.
+
std::ios_base::failure
+When iostream objects are requested to throw exceptions on stream buffer
+errors, the type of exception thrown has changed to use the
+new libstdc++ ABI
+introduced in GCC 5. Code which does
+catch (const std::ios::failure&)
or similar will not catch
+the exception if it is built using the old ABI. To ensure the exception is
+caught either compile the catch handler using the new ABI, or use a handler
+of type std::exception
(which will catch the old and new versions
+of std::ios_base::failure
) or a handler of type
+std::system_error
.
+
std::function
constructed with std::reference_wrapper
+Prior to GCC 7 a std::function
constructed with a
+std::reference_wrapper<T>
would unwrap the argument and
+store a target of type T
, and target_type()
would
+return typeid(T)
. GCC 7 has been changed to match the behavior
+of other implementations and not unwrap the argument. This means the target
+will be a std::reference_wrapper<T>
and
+target_type()
will return
+typeid(std::reference_wrapper<T>)
.
+Code which depends on the target type may need to be adjusted appropriately.
+
std::shared_ptr
+The behavior of std::shared_ptr<T[]>
and
+std::shared_ptr<T[N]>
has changed to match the semantics
+in the C++17 draft. Previously specializations of std::shared_ptr
+for array types had unhelpful semantics and were hard to use correctly, so the
+semantics have changed to match the C++17 behavior in GCC 7. Code which uses
+specializations for array types may continue to work in C++11 and C++14 modes,
+but not in C++17 mode. It is possible, although unlikely, that some valid uses
+of array specializations will no longer work with GCC 7 even in C++11 or C++14
+modes. All uses of array specialization should be adjusted to match the C++17
+semantics which will be standardized soon. Code which only uses specializations
+of std::shared_ptr<T>
for non array-type is unaffected.
+
+
+ + +