defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
this pulls in by default, still provides GCJ/libgcj (as the last GCC-based
port doing so), but unlike C, C++, or Fortran we do not create any symlink
for Java and users may also change the default version of GCC, so really
nothing Java-specific here.
or less ended up identical to lang/gcc5 now that we differentiate between
lang/gccX-devel and lang/gccX ports, by (or as) a meta-port that pulls in
the respective lang/gccX port (based on the setting of $GCC_DEFAULT) and
defines gcc, g++, and gfortran as symlinks to the respective versioned
binaries.
This is the end of a long journey establishing this infrastructure
which is now similar to the one of the python ports, for example,
and makes upgrading the default as well as adjusting the default
locally a lot easier.
(PORTVERSION remains at 5.4.0 for now to avoid PORTEPOCH, but
PORTREVISION gets a bump.)
Suggested by: tijl (a while ago)
Collection (requested by USE_GCC=yes and various USES=compiler
invocations) from GCC 4.9.4 to GCC 5.4.
files/patch-arm-support and files/patch-gcc_system.h have become
obsolete. New patches files/patch-arm-unwind-cxx-support and
files/patch-libc++ help support arm targets and new libc++ in base.
ONLY_FOR_ARCHS now also includes arm.
A new option GRAPHITE_DESC, off by default for now, adds support for
Graphite loop optimizations.
Finally, conflicts with other lang/gcc* ports are adjusted suitably.
In terms of changes for users, this upgrade brings the following:
The default mode for C is now -std=gnu11 instead of -std=gnu89.
New warning options -Wc90-c99-compat and -Wc99-c11-compat may
prove useful on that front.
The C++ front end now has full C++14 language support including
C++14 variable templates, C++14 aggregates with non-static data
member initializers, C++14 extended constexpr, and more.
The Standard C++ Library (libstdc++) has full C++11 support and
experimental full C++14 support. It uses a new ABI by default.
There have been significant improvements to inter-procedural optimizations
and link-time optimization such as One Definition Rule based merging of C++
types as well as register allocation.
OpenMP 4.0 specification offloading features are now supported by the C,
C++, and Fortran compilers. Cilk Plus, an extension to the C and C++
languages to support data and task parallelism, has been added as well.
New warning options -Wswitch-bool, -Wlogical-not-parentheses,
-Wbool-compare and -Wsizeof-array-argument may prove useful as
may new preprocessor directives __has_include, __has_include_next,
and __has_attribute.
GCC can now be built as a shared library for embedding in other processes
(such as interpreters), suitable for Just-In-Time compilation to machine
code. This provides a C API and a C++ wrapper API.
Many code generation improvements for AArch64, ARM, support for
AVX-512{BW,DQ,VL,IFMA,VBMI} and Intel MPX on x86-64, and generally
improvements on many targets.
The Local Register Allocator (LRA) now contains a rematerialization
subpass and is able to reuse the PIC hard register on x86/x86-64 to
improve performance of position independent code.
https://gcc.gnu.org/gcc-5/changes.html has a more extensive set of
changes and https://gcc.gnu.org/gcc-5/porting_to.html has a solid
overview of issue you may encountering porting to this new version.
PR: 216707, 218125
Tested by: antoine (-exp runs)
Supported by: jbeich, tcberner, and others
Remove an extraneous definition of DISTVERSION (which in general we
only need for ports tracking weekly GCC snapshots) and simplify the
definition of GCC_VERSION.
Reported by: andreast [1]
locale set by the user. Add LANG=C and LC_ALL=C at the beginning of
bsd.port.mk and export them so all commands are executed with the C locale.
LC_ALL=C overrides all other LC_* variables. LANG is used by setlocale(3)
as default value for LC_* variables, so normally it isn't used when LC_ALL
is set, but there's code out there that looks at LANG directly so it's safer
to set it as well. The only commands not captured by this are !=
assignments before any inclusion of bsd.port.*mk.
Introduce USE_LOCALE=<locale> that adds LANG=<locale> and LC_ALL=<locale> to
CONFIGURE_ENV and MAKE_ENV so upstream build systems can be executed with a
different locale (e.g. USE_LOCALE=en_US.UTF-8).
PR: 215882
Exp-run by: antoine
Approved by: portmgr (antoine)
Collection as well as the lang/gcc port from GCC 4.8.5 to GCC 4.9.4!
See http://gcc.gnu.org/gcc-4.9/changes.html for an extensive list of
changes and http://gcc.gnu.org/gcc-4.9/porting_to.html for information
on how to port to that new version (if necessary).
files/java-patch-hier required adjustments, gcc/files/patch-arm-libcpp
is not needed any longer (merged upstream), and we're also loosing the
local Stack Protector patches/backports.
PR: 196712
Tested by: antoine (-exp runs)
Supported by: antoine, kwm, and others
GCC can be mis-built, leading to an internal compiler error building
libgcc/libgcov.c, at least on FreeBSD 11.
Adjust OPTIONS_DEFINE_powerpc64 and OPTIONS_DEFAULT_powerpc64
incrementally (with +=) to avoid overwriting settings defined
at the top of the Makefile (or child ports). [1]
Submitted by: swills [1]
Reported by: swills
command-line options. According to POSIX, string comparisons (and
hence sorting) are to be performed based on the locale's collating
order. Alas GNU AWK only does so in POSIX mode, whereas starting
with FreeBSD 11 we do so by default, running into a bug (or false
assumption) with that script used by GCC.
Setting MAKE_ARGS such that AWK is always invoked in the C locale
works around this bug.
PR: 210122, 211742
Submitted by: jkim
of GCC including lang/gcc:
Only override CONFIGURE_TARGET for amd64 which is x86-64/x86_64 for the
rest of the world including GNU and GCC. For all other architectures
it already defaults to the value we were setting.
to the versioned executable (gfortran48, gcc48, and g++48).
These standard names are going to remain in place in case of version
upgrades and constitute the default, and expected by users, names.
Suggested by: db
Reviewed by: db
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. This change is the second attempt at doing this: the
first attempt went in r401072 and was reverted in r401074 because the diff
was bogus and enabled the new MULTILIB option under all platforms instead
of just powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
I'm not sure what happened exactly but I think I committed the change from
the wrong client. The applied change enabled the MULTILIB option for all
architectures and not only powerpc64. Let's just revert the commit and do
it properly from scratch; other things might be wrong so I wanna take a
closer look, and it's best to just revert quickly.
This change is the same as r400632, which updated gcc[56]-devel, but now
for gcc{,48,49,5}. Waited a week to ensure the change caused nothing to go
horribly wrong but this change is very low risk because it only affects
powerpc64.
This fixes the build of gcc{,48,49,5} under powerpc64 when the system
is built without the lib32 libraries.
More in detail:
If the system is built with lib32 support (WITH_LIB32, which is the default),
building gcc from ports results in a compiler that can target both 64-bit and
32-bit binaries on powerpc64. However, when lib32 support is disabled
(WITHOUT_LIB32), gcc should only be built with 64-bit support or otherwise
the build fails.
To fix this, explicitly disable 32-bit support when /usr/lib32 is not present
and add a MULTILIB option (which is only defined for powerpc64 when 32-bit
support is possible and defaults to yes to preserve the current behavior) to
allow the user to explicitly control this feature.
Approved by: gerald (maintainer), bdrewery (mentor), andreast
Differential Revision: https://reviews.freebsd.org/D3952
While the feature has a great value, it is right now breaking the build of
lang/gcc. Given the importance of lang/gcc it is better to revert now and
reapply the patch once it has been fixed and passes an exp-run on all supported
version
With hat: portmgr
Upstream gcc 4.8 doesn't have support for this - it'll create threads,
but it won't do any of the thread affinity stuff for FreeBSD.
This allows for OMP_PROC_BIND=true to bind threads to their initial
CPUs, leading to some pretty drastic improvements in performance
for certain NUMA workloads.
Approved by: gerald
This was causing the gcc packages to be generated with a
/usr/local/libdata/ldconfig/gcc file. All were conflicting. Bump
PORTREVISION to fix packages built during this time.
With hat: portmgr
Reported by: sunpoet
The larger part of the patch is a backport from gcc trunk which is sent
upstream for approval.
Thanks to Sean Bruno for testing, Andrew Turner for explaining me fine details
and Gerald for approving.
Approved by: gerald (maintainer)
script to assume the BUILD_CONFIG is set to bootstrap-debug, instead of
letting it auto-detect.
With clang 3.5.0 this auto-detection can fail, due to a discrepancy [1]
[2] in its debug information, when objects are produced with and without
-g. When the auto-detection fails, gcc will compare objects with full
debug information during the stage comparisons, and this sometimes
causes those stage comparisons to fail unexpectedly.
[1] http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141222/250134.html
[2] http://llvm.org/PR22046
Approved by: gerald (maintainer)
to GCC 4.8.3.
This entails updating the lang/gcc port as well as changing the default
in Mk/bsd.default-versions.mk, and it replaces the CONFLICT between the
lang/gcc and lang/gcc47 ports by lang/gcc48.
GCC now uses C++ as its implementation language and performs more
aggressive loop analysis which can be disabled via the
-fno-aggressive-loop-optimizations command-line option.
Compilation of extremely large functions has been signficantly improved,
as have interprocedural optimizations.
A new optimization level -Og has been introduced. It addresses the need
for fast compilation and a superior debugging experience while providing
a reasonable level of run-time performance. This should be better
suitable for development than the default -O0.
A new local register allocator (LRA) has been implemented, which replaces
the 26 year old reload pass and improves generated code quality. For now
it is active on the x86 and x86-64 targets.
AddressSanitizer, a fast memory error detector, has been added and can be
enabled via -fsanitize=address.
Each diagnostic emitted now includes the original source line and a caret
indicating the column.
The new option -Wpedantic is an alias for -pedantic, which is now deprecated.
The C++ frontend and associated run-time library libstdc++ have gained
support for many additional C++11 features. As with previous releases
the Fortrand frontend has seen many improvements as well.
Support for the AArch64 has been added, and there are many improvements
to the x86/x86-64 backend and others.
See http://gcc.gnu.org/gcc-4.8/changes.html for an extense list of changes;
http://gcc.gnu.org/gcc-4.8/porting_to.html for information on how to port
to that new version.
PR: 192025
Tested by: antoine (-exp runs)
series that closes this branch.
Extend full-regression-test by running contrib/test_summary.
Also clean *.la files in LIBEXEC, and recursively so, there and for
TARGLIB.
