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 X-Patchwork-Id: 721647 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3vBxrB6czvz9tk2 for ; Tue, 31 Jan 2017 04:55:20 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="VvgaBk5S"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; q=dns; s= default; b=NyryXtQjwx4XLN/l8G98MPPS8OWgrdPpTzlpWEZTYr2aL9uwmuzmR D7LMTUXfHjCf7CEIrcxTae6g9AO8rSJh4hfeD0ODpN2Ttk9mIOzuiUZH8hpLt8I0 lot6LFfBoVfgMGebSzcqXw46w9/QR2eJsnQPQDiVRz4Xm5MgMjAuTI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:mime-version:content-type; s= default; bh=VDVDIkZTU6xuQ7N9p2bx0ixzCak=; b=VvgaBk5S+m5z/OPSdPmB gwNwO4svOKpq+33UxeMJbqpV8rXH0jzDg7CUlfRRir53g1ebgaryl6CoKWuw5Tul 9g+V7FEx0+12V7Iw8qJqdbEBXld56KYfE+i+oEn3Ge9hoLKvLr0qWgiJwbb7wb1d 4eB66JU7eJdtvGk7vcfxZfg= Received: (qmail 108798 invoked by alias); 30 Jan 2017 17:55:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 108778 invoked by uid 89); 30 Jan 2017 17:55:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=overloads, Links, gcc-5, porting_tohtml X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Jan 2017 17:55:00 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8E0873D945; Mon, 30 Jan 2017 17:55:00 +0000 (UTC) Received: from localhost (ovpn-116-184.ams2.redhat.com [10.36.116.184]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0UHsxKU000960; Mon, 30 Jan 2017 12:55:00 -0500 Date: Mon, 30 Jan 2017 17:54:58 +0000 From: Jonathan Wakely To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: [wwwdocs] Added /gcc-7/porting_to.html Message-ID: <20170130175458.GV3093@redhat.com> MIME-Version: 1.0 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.1 (2016-10-04) This adds the porting to guide for GCC 7. So far it only has details of C++ changes, mostly in the std::lib. Committed to CVS. Index: htdocs/gcc-7/porting_to.html =================================================================== RCS file: htdocs/gcc-7/porting_to.html diff -N htdocs/gcc-7/porting_to.html --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ htdocs/gcc-7/porting_to.html 30 Jan 2017 17:53:55 -0000 @@ -0,0 +1,159 @@ + + + +Porting to GCC 7 + + + +

Porting to GCC 7

+ +

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

+ + +

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

+ +

Header dependency changes

+ +

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

+ +

Additional overloads of 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. +

+ +

Changes to 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. +

+ +

Changes for array support in 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. +

+ + + +

+

+ + +