Update to the 20110219 snapshot of GCC 4.6.0.
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]

Update to the 20110219 snapshot of GCC 4.6.0.
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]

Update to the 20110205 snapshot of GCC 4.6.0. This finally addresses
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

Update to the 20101120 snapshot of GCC 4.6.0. This brings libquadmath
(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).

Update to the 20100911 snapshot of GCC 4.6.0. This brings one fix for
FreeBSD/ia64 that I made upstream and together with another, which is a
local patch for now, ia64 can become part of ONLY_FOR_ARCHS.

Similar to lang/gcc45, add a new option LTO that enables GCC's new
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.

Update to the 20100821 snapshot of GCC 4.6.0. This now really does not
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.