Since clang++ 6.0.0 now defaults to -std=gnu++14 (similar to g++ 6 and
higher), building gcc48, gcc49 or gcc5 produce quite a number of
"invalid suffix on literal; C++11 requires a space between literal and
identifier" errors. This is because in many places, double quotes are
directly followed by printf helper macros like HOST_WIDE_INT_PRINT.
In gcc 6 and later, spaces were added between the double quotes and the
macros, to fix this issue, but for earlier versions, use a combination
of find, grep and sed to add them mechanically throughout the respective
source trees.
In addition, gcc5 needs a regular patch to fix an incorrect call to
error(), which should have been error_at(). (This was a mismerge by
upstream.)
Approved by: gerald (maintainer)
PR: 224927
MFH: 2018Q1
info is removed) from lang/gcc7 to lang/gcc47, lang/gcc48 and lang/gcc49.
(For more background see revisions 454177 and 454422.)
Reported by: Ports QA Framework, miwi, sobomax
Discussed with: tijl, miwi
Differential Revision: https://reviews.freebsd.org/D10357
but no expiration date at this point (since at least the latter two
still have users in the ports tree and sparc64 relies on the latter).
PR: 222373
Submitted by: Yasuhiro KIMURA <yasu@utahime.org>
- Move ONLY_FOR_ARCHS into the right position of the Makefile.
- Omit a comment describing GCC_VERSION and SUFFIX.
- Do not quote constant strings compared with ${ARCH}. [1]
- Last, but not least the only functional change (and an important one):
Remove headers being created by GCC's fixincludes machinery from
the installation / packaging to avoid breakage when FreeBSD's headers
are changing afterwards. [2]
PR: 221905 [1], 222233 [2]
Submitted by: linimon [1]
associated with it as well as java from CATEGORIES).
In addition to changes to Makefile, pkg-plist, and pkg-descr, this also
removes files/java-patch-hier.
GCC 4.9 was first released in summer 2014 and went end-of-life upstream
a year ago, but GCC 5 is very well established by now and also provides
support for Java (GCJ/libgcj), and so does GCC 6, and this simplifies
this port significantly and also speeds up the build.
While we are here, streamline the setting of INFO.
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
only need for ports tracking weekly GCC snapshots) and simplify
the definition of GCC_VERSION.
Remove traces of armv6hf which no longer exists as an arch. [1]
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)
causing build failures of the kind
/usr/local/bin/ld: classpath/tools/.libs/libgcj_tools_la-tools.o:
unknown relocation type 1383330 for `*UND*'
and generally not that important nor widely used.
Reported by: swills
Discussed with: andreast
While testing the clang390-import branch, I ran into the following
errors building lang/gcc49:
In file included from /wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/c/c-objc-common.c:33:
In file included from /usr/include/c++/v1/new:70:
/usr/include/c++/v1/exception:267:5: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~~~~~
/usr/include/c++/v1/__config:451:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
/wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/system.h:685:13: note: 'fancy_abort' declared here
extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
^
1 error generated.
What is happening here, is that the source file includes gcc/system.h,
which defines abort to fancy_abort, and then the source file includes
<new>, which attempts to call _VSTD::abort() (the _VSTD is a libc++
alias for std::). The macro definition then causes the above breakage.
Newer gcc ports, such as gcc5 and gcc6 don't show this issue, because
upstream gcc first added an include of <algorithm> (which indirectly
includes <new>) in r217348 [1], and later even add a direct include of
<new> in r232736 [2].
Fix it for this version, by adding the direct include of <new> to
gcc/system.h. This makes the 'second' includes of <new> in some .c
files superfluous, but at least they won't result in errors.
[1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217348
[2] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=232736
Approved by: gerald (maintainer)
PR: 212465
MFH: 2016Q3
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: 211742
Submitted by: jkim
branch and release series. There should not be any further releases (nor
even snapshots) of GCC 4.9 going forward.
Adjust the download location etc accordingly.
Update MULTILIB_DESC which now matches newer gcc* ports.
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.
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
