| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This brings eight back ports for the tree, inter-procedural (IPO),
link-time (LTO) optimizers, three for the middle end, four for the
low level (RTL) optimizers, six related to debug information, two
for aarch64, one for x86, two related to OMP, five for the C, twentyone
for the C++ front end and 32 for libstdc++.
In other words, if you're using C++ this is a good one to consider
and test.
files/patch-libcpp_lex.c now came in via upstream, so we can (and
actually have to) remove it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
to work around the 13 years old GCC 4.2 system compiler on powerpc64 in
those cases we are using that.
PR: 245511
Submitted by: pkubaj
Notes:
svn path=/head/; revision=536683
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
issue has not been addressed upstream yet:
clang on rs6000/powerpc* unfortunately poisons user namespace by default
(without any special options or include files being required).
Until that changes (or GCC changes) we need to avoid using vec_step as a
variable name.
PR: 239266
Notes:
svn path=/head/; revision=517843
|
| |
|
|
|
|
|
|
| |
PR: 239419
Approved by: gerald (maintainer)
Notes:
svn path=/head/; revision=507302
|
| |
|
|
|
|
|
|
|
| |
andreast@ has pushed files/patch-amd64-gcc-multilib-support upstream
after the GCC 9.1 release, so this is now on the GCC 9 branch and can
be removed from our tree.
Notes:
svn path=/head/; revision=501580
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC has two runtime libraries: The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s). Both implement many of the
same functions but they also each have their unique functions. When
GCC links programs and libraries there are three possibilities:
1. gcc -static-libgcc or gcc -static: -lgcc
=> Just use libgcc.a.
2. gcc -shared-libgcc: -lgcc_s -lgcc
=> Link with libgcc_s first, so libgcc.a is only used for its unique
functions.
3. gcc: -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
=> Link with libgcc.a first so libgcc_s is only used for its unique
functions (_Unwind_* functions).
Approach 3 is the default for gcc and it's also what clang and clang++ use;
approach 2 is the default for gfortran, g++ and probably other front ends.
This patch makes 3 the default for gfortran. It significantly reduces
the use of libgcc_s. The _Unwind_* functions are also available in the
old base system libgcc_s which means this reduces the need for
-rpath /usr/local/lib/gccN in ports that depend on libraries built with
gfortran. Consider a dependency tree like this:
prog -> libA -> libgcc_s (old base system libgcc_s is fine)
-> libB -> libgcc_s (libB built with gfortran, needs new libgcc_s)
Here prog needs to be linked with -rpath /usr/local/lib/gccN even if it's
a normal C program compiled with clang. Without -rpath it will fail to
start because it loads old libgcc_s first as a dependency of libA and then
it fails to load libB. With this patch libB works with old base system
libgcc_s or may not need libgcc_s at all, so prog does not need to be
linked with -rpath.
Do not bump PORTREVISION, since we'll shortly update to a newer snapshot,
just need a consistent baseline when branching the new lang/gcc9 now that
GCC 9.1 has been released.
PR: 208120
Submitted by: tijl
Notes:
svn path=/head/; revision=501438
|
| |
|
|
|
|
|
|
|
|
|
| |
compile and execute 32-bit binaries with gcc.
The gcc part will be upstreamed as soon as gcc trunk opens for new commits.
On the release front, gcc8, we will merge this commit after a week or so.
Approved by: gerald@
Notes:
svn path=/head/; revision=496295
|
| |
|
|
|
|
|
|
|
|
|
| |
Support for powerpcspe has been removed from upstream GCC in preparation
of the GCC 9 release, so adjust ONLY_FOR_ARCHS and remove our local patch
files/patch-spe-config that we still carry until lang/gcc8 and gcc8-devel.
PR: 234419
Notes:
svn path=/head/; revision=491253
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disable the build/use of libssp/gets-chk since FreeBSD 12 and later
do not feature gets() any longer.
(I was planning to make this part of a routine update, alas last week's
snapshot was broken on i386-unknown-freebsd10.x and so will this week's
still.)
PR: 222796, 231066
Differential Revision: https://reviews.freebsd.org/D12298
Notes:
svn path=/head/; revision=479233
|
| |
|
|
|
|
|
|
| |
files/patch-libcpp-includenew has now been integrated upstream, so
remove it on our end.
Notes:
svn path=/head/; revision=471042
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The failure mode looked as follows:
In file included from /scratch/tmp/gerald/gcc-HEAD/libcpp/system.h:442:
In file included from /usr/include/c++/v1/new:91:
/usr/include/c++/v1/exception:180:5: error: no member named 'fancy_abort'
in namespace 'std::__1'; did you mean simply 'fancy_abort'?
_VSTD::abort();
^~~~~~~
Notes:
svn path=/head/; revision=470722
|
|
|
mainline has become GCC 9 and the 20180429 snapshot of GCC 9.0.0 is
the first of its kind.
Accordingly introduce the gcc9-devel port to track this development
of what ultimately is going to become the GCC 9 release series.
Notes:
svn path=/head/; revision=469251
|
