Make up to 3.80 (documented as minimal permitted version) doesn't
support "else if...".
2015-07-17 Jan Beulich <jbeulich@suse.com>
* config/t-softfp: Split up "else ifneq".
From-SVN: r225920
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
Continuing the cleanups of libgcc soft-fp configuration for
powerpc*-*-linux* in preparation for implementing
TARGET_ATOMIC_ASSIGN_EXPAND_FENV for soft-float and e500, this patch
optimizes the choice of which functions to build for the e500 cases.
For e500v2, use of hardfp is generally right, except that calls to
__unordsf2 and __unorddf2 are actually generated by GCC from
__builtin_isunordered and so they need to be implemented with soft-fp
to avoid recursively calling themselves. For e500v1, hardfp is right
for SFmode (except for __unordsf2) but soft-fp for DFmode (and when
using soft-fp, as usual it's best for the conversions between DFmode
and integers all to come directly from soft-fp rather than some coming
from libgcc2.c). Thus, new variables hardfp_exclusions and
softfp_extras are added that configurations using t-hardfp and
t-softfp can use to achieve the desired effect of selectively mixing
the two sources of functions.
Tested with no regressions for crosses to powerpc-linux-gnuspe (both
e500v1 and e500v2); also checked that the same set of symbols and
versions is exported from shared libgcc before and after the patch.
* config/t-hardfp (hardfp_exclusions): Document new variable for
user to define.
(hardfp_func_list): Exclude functions from $(hardfp_exclusions).
* config/t-softfp (softfp_extras): Document new variable for user
to define.
(softfp_func_list): Add functions from $(softfp_extras).
* config/rs6000/t-e500v1-fp, config/rs6000/t-e500v2-fp: New files.
* config.host (powerpc*-*-linux*): For e500v1, use
rs6000/t-e500v1-fp and t-hardfp; do not use t-softfp-sfdf and
t-softfp-excl. For e500v2, use t-hardfp-sfdf, rs6000/t-e500v2-fp
and t-hardfp; do not use t-softfp-sfdf and t-softfp-excl.
From-SVN: r216835
