GCC 4.2 Release Series
Changes, New Features, and Fixes

Caveats

• GCC no longer accepts the -fshared-data option. This option has had no effect in any GCC 4 release; the targets to which the option used to apply had been removed before GCC 4.0.

General Optimizer Improvements

New Languages and Language specific improvements

C family

• The pragma redefine_extname will now macro expand its tokens for compatibility with SunPRO.

C++

• The (undocumented) extension which permitted templates with default arguments to be bound to template template parameters with fewer parameters has been removed. For example:

  	template <template <typename> class C>
  	void f(C<double>) {}
  
  	template <typename T, typename U = int>
  	struct S {};
  
  	template void f(S<double>);
        

  is no longer accepted by G++. The reason this code is not accepted is that S is a template with two parameters; therefore, it cannot be bound to C which has only one parameter.
• The <?, >?, <?=, and >?= operators, deprecated in previous GCC releases, have been removed.
• The command line option -fconst-strings, deprecated in previous GCC releases, has been removed.
• The configure variable enable-__cxa_atexit is now enabled by default for more targets. Enabling this variable is necessary in order for static destructors to be executed in the correct order, but it depends upon the presence of a non-standard C library in the target library in order to work. The variable is now enabled for more targets which are known to have suitable C libraries.

Java (GCJ)

• A new command line option -static-libgcj has been added for targets that use a linker compatible with GNU Binutils. As its name implies, this causes libgcj to be linked statically. In some cases this causes the resulting executable to start faster and use less memory than if the shared version of libgcj were used. However caution should be used as it can also cause essential parts of the library to be omitted. Some of these issues are discussed in: http://gcc.gnu.org/wiki/Statically%20linking%20libgcj
• fastjar is no longer bundled with GCC. To build libgcj, you will need either InfoZIP (both zip and unzip) or an external jar program. In the former case, the GCC build will install a jar shell script that is based on InfoZIP and provides the same functionality as fastjar.

New Targets and Target Specific Improvements

SPARC

• The default CPU setting has been changed from V7 to V9 in 32-bit mode on Solaris 7 and above. This is already the case in 64-bit mode. It can be overridden by specifying --with-cpu at configure time.

M32C

• Various bugfixes have made some functions (notably, functions returning structures) incompatible with previous releases. Recompiling all libraries is recommended. Note that code quality has considerably improved since 4.1, making a recompile even more beneficial.

MIPS

• Added support for the Broadcom SB-1A core.

Obsolete Systems

Documentation improvements

Other significant improvements

Build system improvements

• All the components of the compiler are now bootstrapped by default. This improves the resilience to bugs in the system compiler or binary compatibility problems, as well as providing better testing of GCC 4.2 itself. In addition, if you build the compiler from a combined tree, the assembler, linker, etc. will also be bootstrapped (i.e. built with themselves).

  You can disable this behavior, and go back to the pre-GCC 4.2 set up, by configuring GCC with --disable-bootstrap.

• The rules that configure follows to find target tools resemble more closely the locations that the built compiler will search. In addition, you can use the new configure option --with-target-tools to specify where to find the target tools used during the build, without affecting what the built compiler will use.

  This can be especially useful when building packages of GCC. For example, you may want to build GCC with GNU as or ld, even if the resulting compiler to work with the native assembler and linker. To do so, you can use --with-target-tools to point to the native tools.

Incompatible changes to the build system

• Front-ends external to GCC should modify their Make-lang.in file to replace double-colon rules (e.g. dvi::) with normal rules (like lang.dvi:). Front-end makefile hooks do not use double-colon rules anymore.
• Up to GCC 4.1, a popular way to specify the target tools used during the build was to create directories named gas, binutils, etc. in the build tree, and create links to the tools from there. This does not work anymore when the compiler is bootstrapped. The new configure option --with-target-tools provides a better way to achieve the same effect, and works for all native and cross settings.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

These pages are maintained by the GCC team.

For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help.
Please send comments on these web pages and the development of GCC to our developer mailing list at gcc@gnu.org or gcc@gcc.gnu.org. All of our lists have public archives.

Copyright (C) Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

Last modified 2006-09-12