This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[wwwdocs] gcc-4.7/porting_to.html
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org, jakub at redhat dot com
- Date: Wed, 11 Jan 2012 16:11:10 -0800
- Subject: [wwwdocs] gcc-4.7/porting_to.html
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 <bkoz@redhat.com>
* 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 ----
+ <html>
+
+ <head>
+ <title>Porting to GCC 4.7</title>
+ </head>
+
+ <body>
+ <h1>Porting to GCC 4.7</h1>
+
+ <p>
+ The GCC 4.7 release series differs from previous GCC releases in more
+ than the usual list of
+ <a href="http://gcc.gnu.org/gcc-4.7/changes.html";>changes</a>. 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.
+ </p>
+
+ <p>
+ 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.
+ </p>
+
+ <h2>General issues</h2>
+
+ <h3>Use of invalid flags when linking</h3>
+
+ <p>
+ 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,
+ </p>
+
+ <pre>
+ gcc -Wl -o foo foo.o -mflat_namespace
+ </pre>
+
+ <p>
+ Now produces the following error
+ </p>
+
+ <pre>
+ error: unrecognized command line option â??-Wlâ??
+ error: unrecognized command line option â??-mflat_namespaceâ??
+ </pre>
+
+ <p>
+ Invalid options need to be removed from the command line or replaced
+ by something that is valid.
+ </p>
+
+ <h2>C language issues</h2>
+
+ <h3>Boolean type promotion changes</h3>
+
+ <p>
+ 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.
+ </p>
+
+ <pre>
+ checking for stdbool.h that conforms to C99... no
+ </pre>
+
+
+ <h2>C++ language issues</h2>
+
+ <h3>Header dependency changes</h3>
+
+ <p>
+ Many of the standard C++ library include files have been edited to no
+ longer include <unistd.h> to remove <a href="http://gcc.gnu.org/PR49745";>namespace pollution</a>.
+ </p>
+
+ <p>
+ As such, C++ programs that used functions
+ including <code>truncate</code>, <code>sleep</code>
+ or <code>pipe</code> without first including <unistd.h> will no
+ longer compile. The diagnostic produced is similar to:
+ </p>
+
+ <pre>
+ error: â??truncateâ?? was not declared in this scope
+ </pre>
+
+ <pre>
+ error: â??sleepâ?? was not declared in this scope
+ </pre>
+
+ <pre>
+ error: â??pipeâ?? was not declared in this scope
+ </pre>
+
+ <pre>
+ error: there are no arguments to 'offsetof' that depend on a template
+ parameter, so a declaration of 'offsetof' must be available
+ </pre>
+
+ <p>
+ Fixing this issue is easy: just include <unistd.h>.
+ </p>
+
+ <h3>Note on proper checking for thread support</h3>
+
+ <p>
+ At no time, should user-level code use private
+ GCC-implementation-space macros such as
+ <code>_GLIBCXX_HAS_GTHREADS</code> to determine at compile-time
+ concurrency support. Instead, use the POSIX
+ macro <code>_REENTRANT</code>.
+ </p>
+
+ <h3>Name lookup changes</h3>
+
+ <p>
+ The C++ compiler no longer performs an extra unqualified lookups that
+ had performed in the past, namely <a href="http://gcc.gnu.org/PR24163";>dependant base class scope lookups</a> and
+ <a href="http://gcc.gnu.org/PR29131";>unqualified template function</a>
+ lookups.
+ </p>
+
+ <p>
+ C++ programs that depended on the compiler's previous behavior may
+ longer compile. For example, code such as
+ </p>
+
+ <pre>
+ template<typename T>
+ int t(T i)
+ { return f(i); }
+
+ int
+ f(int i)
+ { return i; }
+
+ int
+ main()
+ {
+ return t(1);
+ }
+ </pre>
+
+
+ <p>
+ Will result in the following diagnostic:
+ </p>
+ <pre>
+ 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
+ </pre>
+
+ <p>
+ To fix, make sure the function <code>f</code> in the code above is
+ declared before first use in function <code>t</code>. Like so:
+ </p>
+
+ <pre>
+ int
+ f(int i)
+ { return i; }
+
+ template<typename T>
+ int t(T i)
+ { return f(i); }
+
+ int
+ main()
+ {
+ return t(1);
+ }
+ </pre>
+
+ <p>
+ This can be temporarily worked around by using <code>-fpermissive</code>.
+ </p>
+
+ <h3>Detection of redeclared variable names in nested scopes</h3>
+
+ <p>
+ The C++ compiler no longer allows identical identifiers in some <a href="http://gcc.gnu.org/PR2288";>nested scopes</a>. Namely:
+ </p>
+
+ <pre>
+ void f(int);
+
+ int main()
+ {
+ for (int i=0;;++i)
+ {
+ int i=5;
+ f(i);
+ }
+ return 0;
+ }
+ </pre>
+
+ <p>
+ Now results in the error:
+ <p>
+
+ <pre>
+ error: redeclaration of â??int iâ??
+ error: â??int iâ?? previously declared here
+ </pre>
+
+ <p>
+ To fix this, rename the inner variable from <code>i</code> to a
+ distinct identifier.
+ </p>
+
+ <h3>User-defined literals and whitespace</h3>
+
+ <p>
+ 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.
+ </p>
+
+ <p>
+ 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
+ </p>
+
+ <pre>
+ const char *p = "foobar"__TIME__;
+ </pre>
+
+ <p>In C++03, the <code>__TIME__</code> macro expands to some string literal and is concatenated with the other one. In C++11 <code>__TIME__</code> isn't expanded, instead operator "" <code>__TIME__</code> is being looked up, resulting in the following diagnostic:
+ </p>
+
+ <pre>
+ error: unable to find string literal operator â??operator"" __TIME__â??
+ </pre>
+
+ <p>
+ 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.
+ </p>
+
+ <!--
+ <h3>Java issues</h3>
+ -->
+
+ <h3>Links</h3>
+
+ <p>
+ Jakub Jelinek,
+ <a href="https://lists.fedoraproject.org/pipermail/devel/2011-December/160723.html";>GCC
+ 4.7 related common package rebuild failures (was Re: mass rebuild status)</a>
+ </p>
+
+
+ </body>
+ </html>
+
+