about summary refs log tree commit diff
path: root/bits
Commit message (Collapse)AuthorAgeFilesLines
* socket: Use may_alias on sockaddr structs (bug 19622)Florian Weimer2024-05-181-2/+2
| | | | | | | | | | | | | | This supports common coding patterns. The GCC C front end before version 7 rejects the may_alias attribute on a struct definition if it was not present in a previous forward declaration, so this attribute can only be conditionally applied. This implements the spirit of the change in Austin Group issue 1641. Suggested-by: Marek Polacek <polacek@redhat.com> Suggested-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Sam James <sam@gentoo.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* login: Use unsigned 32-bit types for seconds-since-epochFlorian Weimer2024-04-191-2/+2
| | | | | | | | | | | | These fields store timestamps when the system was running. No Linux systems existed before 1970, so these values are unused. Switching to unsigned types allows continued use of the existing struct layouts beyond the year 2038. The intent is to give distributions more time to switch to improved interfaces that also avoid locking/data corruption issues. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* login: structs utmp, utmpx, lastlog _TIME_BITS independence (bug 30701)Florian Weimer2024-04-191-2/+4
| | | | | | | | | These structs describe file formats under /var/log, and should not depend on the definition of _TIME_BITS. This is achieved by defining __WORDSIZE_TIME64_COMPAT32 to 1 on 32-bit ports that support 32-bit time_t values (where __time_t is 32 bits). Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Refer to C23 in place of C2X in glibcJoseph Myers2024-02-012-19/+19
| | | | | | | | | | | | | | | WG14 decided to use the name C23 as the informal name of the next revision of the C standard (notwithstanding the publication date in 2024). Update references to C2X in glibc to use the C23 name. This is intended to update everything *except* where it involves renaming files (the changes involving renaming tests are intended to be done separately). In the case of the _ISOC2X_SOURCE feature test macro - the only user-visible interface involved - support for that macro is kept for backwards compatibility, while adding _ISOC23_SOURCE. Tested for x86_64.
* Implement C23 <stdbit.h>Joseph Myers2024-01-031-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C23 adds a header <stdbit.h> with various functions and type-generic macros for bit-manipulation of unsigned integers (plus macro defines related to endianness). Implement this header for glibc. The functions have both inline definitions in the header (referenced by macros defined in the header) and copies with external linkage in the library (which are implemented in terms of those macros to avoid duplication). They are documented in the glibc manual. Tests, as well as verifying results for various inputs (of both the macros and the out-of-line functions), verify the types of those results (which showed up a bug in an earlier version with the type-generic macro stdc_has_single_bit wrongly returning a promoted type), that the macros can be used at top level in a source file (so don't use ({})), that they evaluate their arguments exactly once, and that the macros for the type-specific functions have the expected implicit conversions to the relevant argument type. Jakub previously referred to -Wconversion warnings in type-generic macros, so I've included a test with -Wconversion (but the only warnings I saw and fixed from that test were actually in inline functions in the <stdbit.h> header - not anything coming from use of the type-generic macros themselves). This implementation of the type-generic macros does not handle unsigned __int128, or unsigned _BitInt types with a width other than that of a standard integer type (and C23 doesn't require the header to handle such types either). Support for those types, using the new type-generic built-in functions Jakub's added for GCC 14, can reasonably be added in a followup (along of course with associated tests). This implementation doesn't do anything special to handle C++, or have any tests of functionality in C++ beyond the existing tests that all headers can be compiled in C++ code; it's not clear exactly what form this header should take in C++, but probably not one using macros. DIS ballot comment AT-107 asks for the word "count" to be added to the names of the stdc_leading_zeros, stdc_leading_ones, stdc_trailing_zeros and stdc_trailing_ones functions and macros. I don't think it's likely to be accepted (accepting any technical comments would mean having an FDIS ballot), but if it is accepted at the WG14 meeting (22-26 January in Strasbourg, starting with DIS ballot comment handling) then there would still be time to update glibc for the renaming before the 2.39 release. The new functions and header are placed in the stdlib/ directory in glibc, rather than creating a new toplevel stdbit/ or putting them in string/ alongside ffs. Tested for x86_64 and x86.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-0180-80/+80
|
* linux: Add posix_spawnattr_{get, set}cgroup_np (BZ 26371)Adhemerval Zanella Netto2023-09-051-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | These functions allow to posix_spawn and posix_spawnp to use CLONE_INTO_CGROUP with clone3, allowing the child process to be created in a different cgroup version 2. These are GNU extensions that are available only for Linux, and also only for the architectures that implement clone3 wrapper (HAVE_CLONE3_WRAPPER). To create a process on a different cgroupv2, one can use the: posix_spawnattr_t attr; posix_spawnattr_init (&attr); posix_spawnattr_setflags (&attr, POSIX_SPAWN_SETCGROUP); posix_spawnattr_setcgroup_np (&attr, cgroup); posix_spawn (...) Similar to other posix_spawn flags, POSIX_SPAWN_SETCGROUP control whether the cgroup file descriptor will be used or not with clone3. There is no fallback if either clone3 does not support the flag or if the architecture does not provide the clone3 wrapper, in this case posix_spawn returns EOPNOTSUPP. Checked on x86_64-linux-gnu. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Fix all the remaining misspellings -- BZ 25337Paul Pluzhnikov2023-06-022-2/+2
|
* Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1Kito Cheng2023-04-281-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | __GLIBC_FLT_EVAL_METHOD will effect the definition of float_t and double_t, currently we'll set __GLIBC_FLT_EVAL_METHOD to 2 when __FLT_EVAL_METHOD__ is -1, that means we'll define float_t and double_t to long double. However some target isn't natively (HW) support long double like AArch64 and RISC-V, they defined long double as 128-bits IEEE 754 floating point type. That means setting __GLIBC_FLT_EVAL_METHOD to 2 will cause very inefficient code gen for those target who didn't provide native support for long double, and that's violate the spirit float_t and double_t - most efficient types at least as wide as float and double. So this patch propose to remap __GLIBC_FLT_EVAL_METHOD to 0 rather than 2 when __FLT_EVAL_METHOD__ is -1, which means we'll use float/double rather than long double for float_t and double_t. Note: __FLT_EVAL_METHOD__ == -1 means the precision is indeterminable, which means compiler might using indeterminable precision during optimization/code gen, clang will set this value to -1 when fast math is enabled. Note: Default definition float_t and double_t in current glibc: | __GLIBC_FLT_EVAL_METHOD | float_t | double_t | 0 or 16 | float | double | 1 | double | doulbe | 2 | long double | long double More complete list see math/math.h Note: RISC-V has defined ISA extension to support 128-bits IEEE 754 floating point operations, but only rare RISC-V core will implement that. Related link: [1] LLVM issue (__FLT_EVAL_METHOD__ is set to -1 with Ofast. #60781): https://github.com/llvm/llvm-project/issues/60781 [2] Last version of this patch: https://sourceware.org/pipermail/libc-alpha/2023-February/145622.html Acked-by: Palmer Dabbelt <palmer@rivosinc.com> # RISC-V Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com> Link: https://inbox.sourceware.org/libc-alpha/20230314151948.12892-1-kito.cheng@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
* [hurd] Add MTU_DISCOVER valuesSamuel Thibault2023-02-151-0/+20
|
* hurd: Fix tcflag_t and speed_t types on 64-bitSergey Bugaev2023-02-121-2/+2
| | | | | | | | These are supposed to stay 32-bit even on 64-bit systems. This matches BSD and Linux, as well as how these types are already defined in tioctl.defs Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
* hurd: Fix _NOFLSH valueSamuel Thibault2023-01-151-1/+1
| | | | | | shifting 1 (thus an integer) left 31 bit is undefined behavior. We have to make it an unsigned integer to properly get 0x80000000 (like done in other places).
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-0679-79/+79
|
* Expose all MAP_ constants in <sys/mman.h> unconditionally (bug 29375)Andreas Schwab2022-10-101-14/+8
| | | | | POSIX reserves the MAP_ prefix for <sys/mman.h>, so there is no need to conditionalize their definitions on feature test macros.
* Update _FloatN header support for C++ in GCC 13Joseph Myers2022-09-281-20/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC 13 adds support for _FloatN and _FloatNx types in C++, so breaking the installed glibc headers that assume such support is not present. GCC mostly works around this with fixincludes, but that doesn't help for building glibc and its tests (glibc doesn't itself contain C++ code, but there's C++ code built for tests). Update glibc's bits/floatn-common.h and bits/floatn.h headers to handle the GCC 13 support directly. In general the changes match those made by fixincludes, though I think the ones in sysdeps/powerpc/bits/floatn.h, where the header tests __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing fixincludes patterns. Some places involving special C++ handling in relation to _FloatN support are not changed. There's no need to change the __HAVE_FLOATN_NOT_TYPEDEF definition (also in a form that wouldn't be matched by the fixincludes fixes) because it's only used in relation to macro definitions using features not supported for C++ (__builtin_types_compatible_p and _Generic). And there's no need to change the inline function overloads for issignaling, iszero and iscanonical in C++ because cases where types have the same format but are no longer compatible types are handled automatically by the C++ overload resolution rules. This patch also does not change the overload handling for iseqsig, and there I think changes *are* needed, beyond those in this patch or made by fixincludes. The way that overload is defined, via a template parameter to a structure type, requires overloads whenever the types are incompatible, even if they have the same format. So I think we need to add overloads with GCC 13 for every supported _FloatN and _FloatNx type, rather than just having one for _Float128 when it has a different ABI to long double as at present (but for older GCC, such overloads must not be defined for types that end up defined as typedefs for another type). Tested with build-many-glibcs.py: compilers build for aarch64-linux-gnu ia64-linux-gnu mips64-linux-gnu powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu; glibcs build for aarch64-linux-gnu ia64-linux-gnu i686-linux-gnu mips-linux-gnu mips64-linux-gnu-n32 powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu.
* non-linux: bits/in.h: Add more RFC optionsSamuel Thibault2022-08-151-0/+10
|
* socket: Check lengths before advancing pointer in CMSG_NXTHDRArjun Shankar2022-08-021-7/+33
| | | | | | | | | | | | | | | | | The inline and library functions that the CMSG_NXTHDR macro may expand to increment the pointer to the header before checking the stride of the increment against available space. Since C only allows incrementing pointers to one past the end of an array, the increment must be done after a length check. This commit fixes that and includes a regression test for CMSG_FIRSTHDR and CMSG_NXTHDR. The Linux, Hurd, and generic headers are all changed. Tested on Linux on armv7hl, i686, x86_64, aarch64, ppc64le, and s390x. [BZ #28846] Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
* linux: Add process_madviseAdhemerval Zanella2022-06-021-0/+21
| | | | | | | | | | It was added on Linux 5.10 (ecb8ac8b1f146915aa6b96449b66dd48984caacc) with the same functionality as madvise but using a pidfd of the target process. Checked on x86_64-linux-gnu and i686-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* elf: Issue la_symbind for bind-now (BZ #23734)Adhemerval Zanella2022-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The audit symbind callback is not called for binaries built with -Wl,-z,now or when LD_BIND_NOW=1 is used, nor the PLT tracking callbacks (plt_enter and plt_exit) since this would change the expected program semantics (where no PLT is expected) and would have performance implications (such as for BZ#15533). LAV_CURRENT is also bumped to indicate the audit ABI change (where la_symbind flags are set by the loader to indicate no possible PLT trace). To handle powerpc64 ELFv1 function descriptor, _dl_audit_symbind requires to know whether bind-now is used so the symbol value is updated to function text segment instead of the OPD (for lazy binding this is done by PPC64_LOAD_FUNCPTR on _dl_runtime_resolve). Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, powerpc64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-0178-78/+78
| | | | | | | | | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
* x86-64: Add vector tan/tanf implementation to libmvecSunil K Pandey2021-12-301-0/+11
| | | | | | | | Implement vectorized tan/tanf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector tan/tanf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector erfc/erfcf implementation to libmvecSunil K Pandey2021-12-301-0/+11
| | | | | | | | Implement vectorized erfc/erfcf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector erfc/erfcf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector asinh/asinhf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized asinh/asinhf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector asinh/asinhf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector tanh/tanhf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized tanh/tanhf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector tanh/tanhf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector erf/erff implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized erf/erff containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector erf/erff with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector acosh/acoshf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized acosh/acoshf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector acosh/acoshf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector atanh/atanhf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized atanh/atanhf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector atanh/atanhf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector log1p/log1pf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized log1p/log1pf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector log1p/log1pf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector log2/log2f implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized log2/log2f containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector log2/log2f with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector log10/log10f implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized log10/log10f containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector log10/log10f with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector atan2/atan2f implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized atan2/atan2f containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector atan2/atan2f with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector cbrt/cbrtf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized cbrt/cbrtf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector cbrt/cbrtf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector sinh/sinhf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized sinh/sinhf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector sinh/sinhf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector expm1/expm1f implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized expm1/expm1f containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector expm1/expm1f with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector cosh/coshf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized cosh/coshf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector cosh/coshf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector exp10/exp10f implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized exp10/exp10f containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector exp10/exp10f with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector exp2/exp2f implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized exp2/exp2f containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector exp2/exp2f with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector hypot/hypotf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized hypot/hypotf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector hypot/hypotf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector asin/asinf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized asin/asinf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector asin/asinf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* x86-64: Add vector atan/atanf implementation to libmvecSunil K Pandey2021-12-291-0/+11
| | | | | | | | Implement vectorized atan/atanf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector atan/atanf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* elf: Add _dl_find_object functionFlorian Weimer2021-12-281-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | It can be used to speed up the libgcc unwinder, and the internal _dl_find_dso_for_object function (which is used for caller identification in dlopen and related functions, and in dladdr). _dl_find_object is in the internal namespace due to bug 28503. If libgcc switches to _dl_find_object, this namespace issue will be fixed. It is located in libc for two reasons: it is necessary to forward the call to the static libc after static dlopen, and there is a link ordering issue with -static-libgcc and libgcc_eh.a because libc.so is not a linker script that includes ld.so in the glibc build tree (so that GCC's internal -lc after libgcc_eh.a does not pick up ld.so). It is necessary to do the i386 customization in the sysdeps/x86/bits/dl_find_object.h header shared with x86-64 because otherwise, multilib installations are broken. The implementation uses software transactional memory, as suggested by Torvald Riegel. Two copies of the supporting data structures are used, also achieving full async-signal-safety. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Set default __TIMESIZE default to 64Adhemerval Zanella2021-12-231-3/+1
| | | | This is expected size for newer ABIs.
* x86-64: Add vector acos/acosf implementation to libmvecSunil K Pandey2021-12-221-0/+11
| | | | | | | | Implement vectorized acos/acosf containing SSE, AVX, AVX2 and AVX512 versions for libmvec as per vector ABI. It also contains accuracy and ABI tests for vector acos/acosf with regenerated ulps. Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* nptl: Extract <bits/atomic_wide_counter.h> from pthread_cond_common.cFlorian Weimer2021-11-171-0/+35
| | | | | | | | | | | | | And make it an installed header. This addresses a few aliasing violations (which do not seem to result in miscompilation due to the use of atomics), and also enables use of wide counters in other parts of the library. The debug output in nptl/tst-cond22 has been adjusted to print the 32-bit values instead because it avoids a big-endian/little-endian difference. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* elf: Move LAV_CURRENT to link_lavcurrent.hAdhemerval Zanella2021-11-151-0/+25
| | | | No functional change.
* Add missing braces to bsearch inline implementation [BZ #28400]Florian Weimer2021-09-301-1/+3
| | | | | | | | | | GCC treats the pragma as a statement, so that the else branch only consists of the pragma, not the return statement. Fixes commit a725ff1de965f4cc4f36a7e8ae795d40ca0350d7 ("Suppress -Wcast-qual warnings in bsearch"). Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
* Suppress -Wcast-qual warnings in bsearchJonathan Wakely2021-09-301-1/+8
| | | | | | | | | | The first cast to (void *) is redundant but should be (const void *) anyway, because that's the type of the lvalue being assigned to. The second cast is necessary and intentionally not const-correct, so tell the compiler not to warn about it. Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Update floating-point feature test macro handling for C2XJoseph Myers2021-06-011-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ISO C2X has made some changes to the handling of feature test macros related to features from the floating-point TSes, and to exactly what such features are present in what headers, that require corresponding changes in glibc. * For the few features that were controlled by __STDC_WANT_IEC_60559_BFP_EXT__ (and the corresponding DFP macro) in C2X, there is now instead a new feature test macro __STDC_WANT_IEC_60559_EXT__ covering both binary and decimal FP. This controls CR_DECIMAL_DIG in <float.h> (provided by GCC; I implemented support for the new feature test macro for GCC 11) and the totalorder and payload functions in <math.h>. C2X no longer says anything about __STDC_WANT_IEC_60559_BFP_EXT__ (so it's appropriate for that macro to continue to enable exactly the features from TS 18661-1). * The SNAN macros for each floating-point type have moved to <float.h> (and been renamed in the process). Thus, the copies in <math.h> should only be defined for __STDC_WANT_IEC_60559_BFP_EXT__, not for C2X. * The fmaxmag and fminmag functions have been removed (replaced by new functions for the new min/max operations in IEEE 754-2019). Thus those should also only be declared for __STDC_WANT_IEC_60559_BFP_EXT__. * The _FloatN / _FloatNx handling for the last two points in glibc is trickier, since __STDC_WANT_IEC_60559_TYPES_EXT__ is still in C2X (the integration of TS 18661-3 as an Annex, that is, which hasn't yet been merged into the C standard git repository but has been accepted by WG14), so C2X with that macro should not declare some things that are declared for older standards with that macro. The approach taken here is to provide the declarations (when __STDC_WANT_IEC_60559_TYPES_EXT__ is enabled) only when (defined __USE_GNU || !__GLIBC_USE (ISOC2X)), so if C2X features are enabled then those declarations (that are only in TS 18661-3 and not in C2X) will only be provided if _GNU_SOURCE is defined as well. Thus _GNU_SOURCE remains a superset of the TS features as well as of C2X. Some other somewhat related changes in C2X are not addressed here. There's an open proposal not to include the fmin and fmax functions for the _FloatN / _FloatNx types, given the new min/max operations, which could be handled like the previous point if adopted. And the fromfp functions have been changed to return a result in floating type rather than intmax_t / uintmax_t; my inclination there is to treat that like that change of totalorder type (new symbol versions etc. for the ABI change; old versions become compat symbols and are no longer supported as an API). Tested for x86_64 and x86.
* sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305]H.J. Lu2021-02-012-1/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add _SC_MINSIGSTKSZ for the minimum signal stack size derived from AT_MINSIGSTKSZ, which is the minimum number of bytes of free stack space required in order to gurantee successful, non-nested handling of a single signal whose handler is an empty function, and _SC_SIGSTKSZ which is the suggested minimum number of bytes of stack space required for a signal stack. If AT_MINSIGSTKSZ isn't available, sysconf (_SC_MINSIGSTKSZ) returns MINSIGSTKSZ. On Linux/x86 with XSAVE, the signal frame used by kernel is composed of the following areas and laid out as: ------------------------------ | alignment padding | ------------------------------ | xsave buffer | ------------------------------ | fsave header (32-bit only) | ------------------------------ | siginfo + ucontext | ------------------------------ Compute AT_MINSIGSTKSZ value as size of xsave buffer + size of fsave header (32-bit only) + size of siginfo and ucontext + alignment padding. If _SC_SIGSTKSZ_SOURCE or _GNU_SOURCE are defined, MINSIGSTKSZ and SIGSTKSZ are redefined as /* Default stack size for a signal handler: sysconf (SC_SIGSTKSZ). */ # undef SIGSTKSZ # define SIGSTKSZ sysconf (_SC_SIGSTKSZ) /* Minimum stack size for a signal handler: SIGSTKSZ. */ # undef MINSIGSTKSZ # define MINSIGSTKSZ SIGSTKSZ Compilation will fail if the source assumes constant MINSIGSTKSZ or SIGSTKSZ. The reason for not simply increasing the kernel's MINSIGSTKSZ #define (apart from the fact that it is rarely used, due to glibc's shadowing definitions) was that userspace binaries will have baked in the old value of the constant and may be making assumptions about it. For example, the type (char [MINSIGSTKSZ]) changes if this #define changes. This could be a problem if an newly built library tries to memcpy() or dump such an object defined by and old binary. Bounds-checking and the stack sizes passed to things like sigaltstack() and makecontext() could similarly go wrong.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2021-01-0274-74/+74
| | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 6694 files FOO. I then removed trailing white space from benchtests/bench-pthread-locks.c and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this diagnostic from Savannah: remote: *** pre-commit check failed ... remote: *** error: lines with trailing whitespace found remote: error: hook declined to update refs/heads/master
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-04 17:08:25 +0000