Enable c, c++, and fortran (and only these) explicitly by default, and
Java when/where available. [1]
Reported by: Scott Allendorf <scott-allendorf@uiowa.edu> [1]
Replace the, now dysfunctional, post-patch target with a configure
option that marks this build of GCC as "FreeBSD Ports Collection". [1]
Reported by: Bjoern Koenig <bkoenig@alpha-tierchen.de> [1]
to sensibly list here, but http://gcc.gnu.org/gcc-4.6/changes.html has a
nice overview.
Some highlights include
- a new quad-precision library that's used by the Fortran frontend
(on x86 and amd64);
- new -Wunused-but-set-variable and -Wunused-but-set-parameter warnings
for C family languages (enabled by -Wall and -Wall -Wextra, too);
- new -Wdouble-promotion warning for implicit promotions to double;
- a new general optimization level -Ofast combines -O3 with options that
can affect standards compliance but result in better optimized code;
- link-time optimizations (LTO) now scaling to large input sizes, using
better heuristics, and optimizing more aggressively;
- new command-line options -fstack-usage and -fstrict-volatile-bitfields
(for precisely defining and accessing memory-mapped peripheral registers);
- function attribute leaf that allows for more aggressive optimizations;
- new data type __int128 for targets having wide enough machine-mode support;
- support for selectively enabling and disabling warnings via
#pragma GCC diagnostic has been added. For instance:
#pragma GCC diagnostic error "-Wuninitialized"
foo(a); /* error is given for this one */
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wuninitialized"
foo(b); /* no diagnostic for this one */
#pragma GCC diagnostic pop
foo(c); /* error is given for this one */
#pragma GCC diagnostic pop
foo(d); /* depends on command line options */
- new command-line option-fmax-errors=N;
- experimental support for some features from the upcoming ISO C1X;
- similarly for ISO C++0x including constexpr, nullptr, noexcept,
unrestricted unions, range-based for loops, opaque enums, implicitly
deleted functions, and implicit move constructors;
- default warning when integers are cast to larger pointer types,
to disable via -Wno-int-to-pointer-cast;
- signficiantly better diagnostics for C++ code;
- loads and loads and loads of improvements to the Fortran frontend;
- a new Go frontend and run-time library;
- massive work on Objective-C and Objective-C++; notably extensive
support for Objective-C 2.0 (not enabled by this port yet);
- support for Intel Core 2 processors (-march=core2, -mtune=core2),
Intel Core i3/i5/i7 processors /with AVS (-march=corei7, -mtune=corei7,
-march=corei7-avx, -mtune=corei7-avx);
- support for AMD Bobcat (fam 14) processors (-march=btver1, -mtune=btver1);
Caveat:
- Most libstdc++ standard headers have been changed to no longer include
the cstddef header as an implementation detail.
This addresses the pollution of common namespace by
share/python/aotcompile.py and share/python/classfile.py which are
now saved in version-specific directories.
By means of an extra patch default code generation on i386 now
defaults to i486 on FreeBSD 6 and above. [1]
Submitted by: tijl [1]
Reported by: Yuri Karaban <tech@askold.net> [1]
PR: 154364 [1]
This addresses the pollution of common namespace by
share/python/aotcompile.py and share/python/classfile.py which now
go into version-specific directories.
By means of an extra patch default code generation on i386 defaults
to i486 on FreeBSD 6 and above. [1]
Submitted by: tijl [1]
Reported by: Yuri Karaban <tech@askold.net> [1]
PR: 154364 [1]
a long standing issue around libgcj that's been hitting us and allows
me to remove the stop gap I had put in place years ago. [1]
PR: 81788 [1]
Feature safe: yes
(better support for 128 bit floating point types, which for now poisons
global include file namespace though this won't be an issue before GCC
4.7 and I have reported it upstream).
link-time optimization framework and optimizations. GCC 4.6 has been
seeing a lot of work since GCC 4.5, but we are still keeping this
disable by default for now
Using LTO adds libelf as a new dependency and in either case the
environment does not have an influence any more. Bumping PORTREVISION
since someone who had libelf on his system previously to this change
would get LTO enabled automatically and then run into problems if libelf
was removed.
work with the ancient version of GNU as that is part of FreeBSD 8.1 and
earlier (and likely later), so where the dependency this port has on
devel/binutils was a strong recommendation until now and necessary to
leverage new processor features and the -mtune=native option when running
on those newer processors, it is now strictly needed on x86-64 at least.
