1
0
mirror of https://git.FreeBSD.org/ports.git synced 2024-11-20 00:21:35 +00:00
freebsd-ports/lang/gcc9/files/patch-gfortran-libgcc
Gerald Pfeifer 0032df7f14 Welcome GCC 9.1, the first release of the GCC 9 series!
https://gcc.gnu.org/gcc-9/changes.html has a comprehensive overview of
many improvements and changes and https://gcc.gnu.org/gcc-8/porting_to.html
addresses issues you may encounter porting to this new version, though
this release series should have fewer of those than previous ones.

To provide a brief overview of some of the more noticable changes:

GCC's diagnostics now print source code with a left margin showing line
numbers.  This is configurable via -fno-diagnostics-show-line-numbers.
Plus there have been lots of further improvements around diagnostic
messages in general as -fopt-info.

As usual a large number of improvements to code generation, including
but by far not limited to the following:
 - Switch expansion (into expressions).
 - Inliner defaults are tuned to better suit modern C++ codebases,
   especially when built with link time optimizations.
 - Hot/cold partitioning is now more precise and aggressive.
 - Improved scalability for very large translation units.
 - Link-time optimization improvements including faster compilation.

A new option -flive-patching=[inline-only-static|inline-clone] has
been introduced to provide a safe compilation for live-patching.

A new pair of profiling options -fprofile-filter-files and
-fprofile-exclude-files help filter which source files are instrumented.

New built-in functions __builtin_expect_with_probability,
__builtin_has_attribute, and __builtin_speculation_safe_value.

Significant effort has been put into refining existing compiler warnings
and adding additional diagnostics. One notable addition is -Wabsolute-value
which warns for calls to standard functions that compute the absolute value
of an argument when a more appropriate standard function is available. For
example, calling abs(3.14) warns because the appropriate function to
compute the absolute value of a double argument is fabs.

The spelling corrector now considers transposed letters, and the threshold
for similarity has been tightened, to avoid nonsensical suggestions.

A new option --completion provides better option completion in a shell
(such as bash).

OpenACC support in C, C++, and Fortran continues to be maintained and
improved. Most of the OpenACC 2.5 specification is implemented.

Version 5.0 of the OpenMP specification is now partially supported in
the C and C++ compilers.

There is now experimental support for the upcoming C2X revision of the
ISO C standard (via the -std=c2x and similar options).

The C++ front end has experimental support for some of the upcoming
C++2a draft features, enabled by the -std=c++2a or -std=gnu++2a options.
This includes range-based for statements with initializer, default
constructible and assignable stateless lambdas, lambdas in unevaluated
contexts, language support for empty data members, allowing pack expansion
in lambda init-capture, likely and unlikely attributes, class types in
non-type template parameters, allowing virtual function calls in constant
expressions, explicit(bool), std::is_constant_evaluated, nested inline
namespaces, etc.

The C++17 implementation is no longer experimental and parallel algorithms
and <execution> and <memory_resource> are available.  Using the types and
functions in <filesystem> does not require linking with -lstdc++fs any more.

On the Fortran side asynchronous I/O is now fully supported; FINDLOC and
IS_CONTIGUOUS and other intrinsics have been implemented.

The MAX and MIN intrinsics are no longer guaranteed to return any
particular value in case one of the arguments is a NaN. This conforms
with the Fortran standard and what other Fortran compilers do.

A new option -fdec-include, set also by -fdec, has been added for
compatibility with legacy code.  With this option, the INCLUDE directive
is parsed also as a statement, which allows it to be written on multiple
source lines with line continuations.

Support for the Cell Broadband Engine (SPU), and thus powerpcspe on
FreeBSD as well, has been removed for lack of upstream maintainership.

Also there's been a minor ABI change on arm* targets (that GCC warns
about by default, controlled by the -Wpsabi option).

Support for the D programming language has been added to GCC, implementing
version 2.076 of the language and run-time library, though this port does
not enable this yet.  Volunteers welcome to test and contribute.
2019-06-01 18:06:12 +00:00

71 lines
2.8 KiB
Plaintext

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.
Upstream is unlikely accept a patch like this because libgfortran calls
some _Unwind_* functions and so always needs libgcc_s. Also because
every Fortran program and library links to libgfortran it makes sense
that option 2 above is the default. On FreeBSD where clang and GCC
compiled code can be mixed and where multiple libgcc_s may be installed,
option 3 is just a lot easier to deal with.
The bug that sparked this is PR 208120 (but note there's a lot of
misleading information in that bug. CMake is not actually doing
anything wrong.)
--- UTC
--- gcc/fortran/gfortranspec.c.orig 2015-06-26 17:47:23 UTC
+++ gcc/fortran/gfortranspec.c
@@ -404,7 +404,7 @@ For more information about these matters
}
}
-#ifdef ENABLE_SHARED_LIBGCC
+#if 0
if (library)
{
unsigned int i;
--- libgfortran/Makefile.in.orig 2019-02-22 14:22:13.000000000 +0000
+++ libgfortran/Makefile.in 2019-02-27 16:27:08.856408000 +0000
@@ -625,7 +625,7 @@
$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
$(HWCAP_LDFLAGS) \
-lm $(extra_ldflags_libgfortran) \
- $(version_arg) -Wc,-shared-libgcc
+ $(version_arg)
libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec $(LIBQUADLIB_DEP)
cafexeclib_LTLIBRARIES = libcaf_single.la