From patchwork Thu Jan 12 00:11:10 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Benjamin Kosnik X-Patchwork-Id: 135536 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]) by ozlabs.org (Postfix) with SMTP id 55DB8B6EFF for ; Thu, 12 Jan 2012 11:11:42 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1326931903; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Date:From:To:Subject:Message-ID:Mime-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=LTCSWjLY18KcbdMpwFd7 hRcfz5w=; b=thEr7/WkzOweg5+RnzSIRNFniiTOF+6PxzOWiXCN3jFlejmz4LdT dkM0qGA+200d55ShT1ciJikASpJEjxz4zzGZ/9jJXhwK/bO0kjqLePxSoORcJbvK 7hzbZVknG9+MU0iMkn8AIBMLv9H5aL9Z7D/zEToDU70IYuAvMJdqdCA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Date:From:To:Subject:Message-ID:Mime-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=MjTM7W89bKhiK5B8Vr3Y0ILtpXA5e6MDILhhahqt8dPCkvpO18Ll+ro2KTRYXm fLOAZnnzm0FsQzoDirmqDjrpdKsSOtGU+hHmCRiLhh/JVxNe0RVoOZPOvCbWUGt2 uglCnQ7WCRKBYoE8NbpN5/lJ28YU43wt59g6lggty2qf4=; Received: (qmail 26993 invoked by alias); 12 Jan 2012 00:11:36 -0000 Received: (qmail 26981 invoked by uid 22791); 12 Jan 2012 00:11:34 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Jan 2012 00:11:16 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0C0BFAr017001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Jan 2012 19:11:15 -0500 Received: from shotwell ([10.3.113.13]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0C0BEXM028051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 19:11:15 -0500 Date: Wed, 11 Jan 2012 16:11:10 -0800 From: Benjamin Kosnik To: gcc-patches@gcc.gnu.org, jakub@redhat.com Subject: [wwwdocs] gcc-4.7/porting_to.html Message-ID: <20120111161110.5b66d228@shotwell> Mime-Version: 1.0 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 As requested by Jakub. I thought it better to get this in, warts and all, and have it be corrected than to dally around again and have it not checked in. -benjamin 2012-01-11 Benjamin Kosnik * htdocs/gcc-4.7/porting_to.html: Add. Index: htdocs/gcc-4.7/porting_to.html =================================================================== RCS file: htdocs/gcc-4.7/porting_to.html diff -N htdocs/gcc-4.7/porting_to.html *** /dev/null 1 Jan 1970 00:00:00 -0000 --- htdocs/gcc-4.7/porting_to.html 12 Jan 2012 00:06:17 -0000 *************** *** 0 **** --- 1,266 ---- + + + + Porting to GCC 4.7 + + + +

Porting to GCC 4.7

+ +

+ The GCC 4.7 release series differs from previous GCC releases in more + than the usual list of + changes. 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 runtime + 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 4.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. +

+ +

General issues

+ +

Use of invalid flags when linking

+ +

+ Earlier releases did not warn or error about completely invalid + options on gcc/g++/gfortran etc. command lines, if nothing was + compiled, but only linking was performed. This is no longer the + case. For example, +

+ +

+ gcc -Wl -o foo foo.o -mflat_namespace 
+

+ +

+ Now produces the following error +

+ +

+ error: unrecognized command line option ‘-Wl’
+ error: unrecognized command line option ‘-mflat_namespace’
+

+ +

+ Invalid options need to be removed from the command line or replaced + by something that is valid. +

+ +

C language issues

+ +

Boolean type promotion changes

+ +

+ The C compiler no longer promotes boolean values in arithmetic + statements to integer values. Configure-related code that checks for + C99's <stdbool.h> may be impacted. If the following line is + newly present in configure logs, then <stdbool.h> support is + incorrectly configured. +

+ +

+ checking for stdbool.h that conforms to C99... no
+

+ + +

C++ language issues

+ +

Header dependency changes

+ +

+ Many of the standard C++ library include files have been edited to no + longer include <unistd.h> to remove namespace pollution. +

+ +

+ As such, C++ programs that used functions + including truncate, sleep + or pipe without first including <unistd.h> will no + longer compile. The diagnostic produced is similar to: +

+ +

+ error: ‘truncate’ was not declared in this scope
+

+ +

+ error: ‘sleep’ was not declared in this scope
+

+ +

+ error: ‘pipe’ was not declared in this scope
+

+ +

+ error: there are no arguments to 'offsetof' that depend on a template
+ parameter, so a declaration of 'offsetof' must be available
+

+ +

+ Fixing this issue is easy: just include <unistd.h>. +

+ +

Note on proper checking for thread support

+ +

+ At no time, should user-level code use private + GCC-implementation-space macros such as + _GLIBCXX_HAS_GTHREADS to determine at compile-time + concurrency support. Instead, use the POSIX + macro _REENTRANT. +

+ +

Name lookup changes

+ +

+ The C++ compiler no longer performs an extra unqualified lookups that + had performed in the past, namely dependant base class scope lookups and + unqualified template function + lookups. +

+ +

+ C++ programs that depended on the compiler's previous behavior may + longer compile. For example, code such as +

+ +

+ template
+ int t(T i)
+ { return f(i); }
+ 
+ int
+ f(int i)
+ { return i; }
+ 
+ int
+ main()
+ {
+   return t(1);
+ }
+

+ + +

+ Will result in the following diagnostic: +

+ In instantiation of ‘int t(T) [with T = int]’:
+   required from here
+   error: ‘f’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
+   note: ‘int f(int)’ declared here, later in the translation unit
+

+ +

+ To fix, make sure the function f in the code above is + declared before first use in function t. Like so: +

+ +

+ int
+ f(int i)
+ { return i; }
+ 
+ template
+ int t(T i)
+ { return f(i); }
+ 
+ int
+ main()
+ {
+   return t(1);
+ }
+

+ +

+ This can be temporarily worked around by using -fpermissive. +

+ +

Detection of redeclared variable names in nested scopes

+ +

+ The C++ compiler no longer allows identical identifiers in some nested scopes. Namely: +

+ +

+ void f(int);
+  
+ int main() 
+ {
+     for (int i=0;;++i) 
+     {
+       int i=5;
+       f(i);
+     }
+     return 0;
+  }
+

+ +

+ Now results in the error: +

+ +

+ error: redeclaration of ‘int i’
+ error: ‘int i’ previously declared here
+

+ +

+ To fix this, rename the inner variable from i to a + distinct identifier. +

+ +

User-defined literals and whitespace

+ +

+ The C++ compiler in ISO C11 mode -std={c++11,c++0x,gnu++11,gnu++0x} + supports user defined literals, which are incompatible with some valid + ISO C++03 code. +

+ +

+ In particular, whitespace is now needed after a string literal and before something that could be a valid user defined literal. Take the valid ISO C++03 code +

+ +

+ const char *p = "foobar"__TIME__;
+

+ +

In C++03, the __TIME__ macro expands to some string literal and is concatenated with the other one. In C++11 __TIME__ isn't expanded, instead operator "" __TIME__ is being looked up, resulting in the following diagnostic: +

+ +

+  error: unable to find string literal operator ‘operator"" __TIME__’
+

+ +

+ This applies to any string literal followed without whitespace by some + macro. To fix, just add some whitespace between the string literal + and the macro name. +

+ + + +

Links

+ +

+ Jakub Jelinek, + GCC + 4.7 related common package rebuild failures (was Re: mass rebuild status) +

+ + + + + +