Commit Graph

8 Commits

Author SHA1 Message Date
Jakub Jelinek
99dee82307 Update copyright years. 2021-01-04 10:26:59 +01:00
Jakub Jelinek
8d9254fc8a Update copyright years.
From-SVN: r279813
2020-01-01 12:51:42 +01:00
Jakub Jelinek
a554497024 Update copyright years.
From-SVN: r267494
2019-01-01 13:31:55 +01:00
Jakub Jelinek
85ec4feb11 Update copyright years.
From-SVN: r256169
2018-01-03 11:03:58 +01:00
Jakub Jelinek
cbe34bb5ed Update copyright years.
From-SVN: r243994
2017-01-01 13:07:43 +01:00
Jakub Jelinek
818ab71a41 Update copyright years.
From-SVN: r232055
2016-01-04 15:30:50 +01:00
Jakub Jelinek
5624e564d2 Update copyright years.
From-SVN: r219188
2015-01-05 13:33:28 +01:00
Joseph Myers
e610393ca7 Make soft-fp symbols into compat symbols for powerpc*-*-linux*.
Continuing preparations for implementing
TARGET_ATOMIC_ASSIGN_EXPAND_FENV for powerpc*-*-linux* soft-float and
e500, this patch makes soft-fp symbols used for those targets into
compat symbols when building with glibc >= 2.19, so that they are only
in shared libgcc for existing binaries requiring them, not in static
libgcc and not available for new links using shared libgcc.  Instead,
new links will get the symbols from libc, which has exported all of
them since 2.19.  (Actually all the symbols were exported from glibc
since 2.4, but some of them were exported by glibc as compat symbols
only - because of a confusion between deliberately present soft-fp
symbols and old accidental reexports of libgcc functions from glibc
2.0 - until 2.19.)

This allows user floating-point arithmetic to interoperate properly
with the state handled by <fenv.h> functions, whether software state
(for soft-float; TLS variables that don't form a public part of
glibc's ABI, so can only be accessed directly by functions within
glibc) or hardware state (for e500 - the copies of the soft-fp
functions in glibc being built to interoperate with the hardware state
whereas those in libgcc aren't).  Previously only glibc's own
functions, and those operations done in hardware on e500, properly
worked with that state, not direct floating-point arithmetic
operations that were implemented in software.

The intended next step is the actual TARGET_ATOMIC_ASSIGN_EXPAND_FENV
implementation.

The test of glibc >= 2.19 uses the same --with-glibc-version configure
option as in the gcc/ directory (but differently implemented; in gcc/
the fallback is to examine headers to find the version, while in
libgcc/ we can use compile for the target and so use AC_COMPUTE_INT).
The TARGET_ATOMIC_ASSIGN_EXPAND_FENV implementation will also only do
anything for glibc >= 2.19, as it will depend on generating calls to
functions __atomic_feholdexcept __atomic_feclearexcept
__atomic_feupdateenv that were added in 2.19 for that purpose (even
for e500, inline code is not readily possible because of the need to
make prctl syscalls from the implementation of these functions).

In order to make symbols compat symbols, the soft-fp files need
wrapping with generated wrappers including asm .symver directives,
which need to name the symbol version in question.  This is extracted
by an awk script from an intermediate stage of generating the .map
file for linking libgcc (that .map itself depends on the objects that
go into the library, so can't be used for this purpose as that would
mean a circular dependency); the extraction is not fully general
regarding the features available in .map generation, but suffices for
the present purpose.

It would make sense for hardfp.c symbols to be compat symbols as well
(in the cases where hardfp.c gets used, the functions in question
should not be used for new links), but this isn't required for the
present purpose, which is only concerned with ensuring that where
functions that should be affected by rounding modes or exceptions get
used, those functions are actually affected by those rounding modes or
exceptions.

Tested with no regressions with cross to powerpc-linux-gnu
(soft-float); c11-atomic-exec-5.c moves from UNSUPPORTED to FAIL, as
expected, now that floating-point arithmetic in user programs uses the
same state as <fenv.h> functions, so the fenv_exceptions test passes,
but TARGET_ATOMIC_ASSIGN_EXPAND_FENV isn't yet implemented.  (For
e500, c11-atomic-exec-5.c was already FAILing, as enough operations
worked with the hardware state for the fenv_exceptions effective
target test to pass.)  Also verified that the exported symbols and
versions are unchanged, with the expected symbols becoming compat
symbols at the same versions, and that with --with-glibc-version=2.18
the symbols remain normal rather than compat symbols.

	* Makefile.in (libgcc.map.in): New target.
	(libgcc.map): Use libgcc.map.in.
	* config/t-softfp (softfp_compat): New variable to be set by
	users.
	[$(softfp_compat) = y] (softfp_map_dep, softfp_set_symver): New
	variables.
	[$(softfp_compat) = y] (softfp_file_list): Use files in the build
	directory.
	[$(softfp_compat) = y] ($(softfp_file_list)): Generate wrappers
	that use compat symbols and disable all code unless [SHARED].
	* config/t-softfp-compat: New file.
	* find-symver.awk: New file.
	* configure.ac (--with-glibc-version): New configure option.
	(ppc_fp_compat): New variable set for powerpc*-*-linux*.
	* configure: Regenerate.
	* config.host (powerpc*-*-linux*): Use ${ppc_fp_compat} for
	soft-float and e500.

From-SVN: r216942
2014-10-30 17:28:30 +00:00