AuroraMiddleware/glibc
1
0
Fork 0
mirror of https://sourceware.org/git/glibc.git synced 2024-11-22 13:00:06 +00:00
Code Issues Packages Projects Releases Wiki Activity
d23965cf88
glibc/math/test-fpucw-ieee.c

28 lines
1.0 KiB
C
Raw Normal View History

Fix static-binary lazy FPU context allocation Long ago static startup did not parse the auxiliary vector and therefore could not get at any `AT_FPUCW' tag to check whether upon FPU context allocation the kernel would use a FPU control word setting different to that provided by the `__fpu_control' variable. Static startup therefore always initialized the FPU control word, forcing immediate FPU context allocation even for binaries that otherwise never used the FPU. As from GIT commit f8f900ecb9096ec47f5b7bb7626e29223c69061a static startup supports parsing the auxiliary vector, so now it can avoid explicit initialization of the FPU control word, just as can dynamic startup, in the usual case where the setting written to the FPU control word would be the same as the kernel uses. This defers FPU context allocation until the binary itself actually pokes at the FPU. Note that the `AT_FPUCW' tag is usually absent from the auxiliary vector in which case _FPU_DEFAULT is assumed to be the kernel default.
2013-09-09 21:36:57 +00:00
/* FPU control word overridden initialization test.
Update copyright dates with scripts/update-copyrights. * All files with FSF copyright notices: Update copyright dates using scripts/update-copyrights. * locale/programs/charmap-kw.h: Regenerated. * locale/programs/locfile-kw.h: Likewise.
2018-01-01 00:32:25 +00:00
Copyright (C) 2013-2018 Free Software Foundation, Inc.
Fix static-binary lazy FPU context allocation Long ago static startup did not parse the auxiliary vector and therefore could not get at any `AT_FPUCW' tag to check whether upon FPU context allocation the kernel would use a FPU control word setting different to that provided by the `__fpu_control' variable. Static startup therefore always initialized the FPU control word, forcing immediate FPU context allocation even for binaries that otherwise never used the FPU. As from GIT commit f8f900ecb9096ec47f5b7bb7626e29223c69061a static startup supports parsing the auxiliary vector, so now it can avoid explicit initialization of the FPU control word, just as can dynamic startup, in the usual case where the setting written to the FPU control word would be the same as the kernel uses. This defers FPU context allocation until the binary itself actually pokes at the FPU. Note that the `AT_FPUCW' tag is usually absent from the auxiliary vector in which case _FPU_DEFAULT is assumed to be the kernel default.
2013-09-09 21:36:57 +00:00
This file is part of the GNU C Library.
The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */
test-fpucw-ieee: Don't use _FPU_IEEE if not defined Not all architectures define this value, and if they don't, just let the test run the same as test-fpucw, with __fpu_control set to _FPU_DEFAULT explicitly.
2013-11-18 18:27:09 +00:00
#ifdef _FPU_IEEE
/* Some architectures don't have _FPU_IEEE. */
# define FPU_CONTROL _FPU_IEEE
#endif
Fix static-binary lazy FPU context allocation Long ago static startup did not parse the auxiliary vector and therefore could not get at any `AT_FPUCW' tag to check whether upon FPU context allocation the kernel would use a FPU control word setting different to that provided by the `__fpu_control' variable. Static startup therefore always initialized the FPU control word, forcing immediate FPU context allocation even for binaries that otherwise never used the FPU. As from GIT commit f8f900ecb9096ec47f5b7bb7626e29223c69061a static startup supports parsing the auxiliary vector, so now it can avoid explicit initialization of the FPU control word, just as can dynamic startup, in the usual case where the setting written to the FPU control word would be the same as the kernel uses. This defers FPU context allocation until the binary itself actually pokes at the FPU. Note that the `AT_FPUCW' tag is usually absent from the auxiliary vector in which case _FPU_DEFAULT is assumed to be the kernel default.
2013-09-09 21:36:57 +00:00
Fix math/test-fpucw-*.c for sysdeps test-fpucw.c overrides. ARM has an override of the test math/test-fpucw.c, to disable (for soft-float testing) definitions of hard-float macros in fpu_control.h that the header normally defines not only when building for hard-float, but also when building for soft-float with _LIBC defined so that libc code can dynamically test whether VFP hardware is present. (_LIBC is defined when building tests, although ideally it wouldn't be.) The override doesn't work for the derived tests test-fpucw-*.c because they use #include "" instead of <> to include test-fpucw.c, so always get the math/ version instead of the ARM sysdeps override. This patch changes them to use <> so the sysdeps override is effective. (test-fpucw-ieee-static.c doesn't need a change because it includes test-fpucw-ieee.c, which isn't itself being overridden, which in turn includes test-fpucw.c with a #include changed by this patch.) Tested for ARM (big-endian soft-float, non-VFP hardware). * math/test-fpucw-ieee.c: Use <> in #include of test-fpucw.c. * math/test-fpucw-static.c: Likewise.
2014-01-16 05:30:52 +00:00
#include <test-fpucw.c>
Fix static-binary lazy FPU context allocation Long ago static startup did not parse the auxiliary vector and therefore could not get at any `AT_FPUCW' tag to check whether upon FPU context allocation the kernel would use a FPU control word setting different to that provided by the `__fpu_control' variable. Static startup therefore always initialized the FPU control word, forcing immediate FPU context allocation even for binaries that otherwise never used the FPU. As from GIT commit f8f900ecb9096ec47f5b7bb7626e29223c69061a static startup supports parsing the auxiliary vector, so now it can avoid explicit initialization of the FPU control word, just as can dynamic startup, in the usual case where the setting written to the FPU control word would be the same as the kernel uses. This defers FPU context allocation until the binary itself actually pokes at the FPU. Note that the `AT_FPUCW' tag is usually absent from the auxiliary vector in which case _FPU_DEFAULT is assumed to be the kernel default.
2013-09-09 21:36:57 +00:00
/* Preempt the library's definition of `__fpu_control'. */
test-fpucw-ieee: Don't use _FPU_IEEE if not defined Not all architectures define this value, and if they don't, just let the test run the same as test-fpucw, with __fpu_control set to _FPU_DEFAULT explicitly.
2013-11-18 18:27:09 +00:00
fpu_control_t __fpu_control = FPU_CONTROL;
Reference in New Issue Copy Permalink