Fixed another precision bug in powf(). This one is in the computation
[t=p_l+p_h High]. We multiply t by lg2_h, and want the result to be
exact. For the bogus float case of the high-low decomposition trick, we
normally discard the lowest 12 bits of the fraction for the high part,
keeping 12 bits of precision. That was used for t here, but it doesnt't
work because for some reason we only discard the lowest 9 bits in the
fraction for lg2_h. Discard another 3 bits of the fraction for t to
compensate.
This bug gave wrong results like:
powf(0.9999999, -2.9999995) = 1.0000002 (should be 1.0000001)
hex values: 3F7FFFFF C03FFFFE 3F800002 3F800001
As explained in the log for the previous commit, the bug is normally
masked by doing float calculations in extra precision on i386's, but is
easily detected by ucbtest on systems that don't have accidental extra
precision.
Reference: 5f20e5ce7f
Original Author: Bruce Evans
(1) The bit for the 1.0 part of bp[k] was right shifted by 4. This
seems to have been caused by a typo in converting e_pow.c to
e_powf.c.
(2) The lower 12 bits of ax+bp[k] were not discarded, so t_h was
actually plain ax+bp[k]. This seems to have been caused by a logic
error in the conversion.
These bugs gave wrong results like:
powf(-1.1, 101.0) = -15158.703 (should be -15158.707)
hex values: BF8CCCCD 42CA0000 C66CDAD0 C66CDAD4
Fixing (1) gives a result wrong in the opposite direction
(hex C66CDAD8), and fixing (2) gives the correct result.
ucbtest has been reporting this particular wrong result on i386 systems
with unpatched libraries for 9 years. I finally figured out the extent
of the bugs. On i386's they are normally hidden by extra precision.
We use the trick of representing floats as a sum of 2 floats (one much
smaller) to get extra precision in intermediate calculations without
explicitly using more than float precision. This trick is just a
pessimization when extra precision is available naturally (as it always
is when dealing with IEEE single precision, so the float precision part
of the library is mostly misimplemented). (1) and (2) break the trick
in different ways, except on i386's it turns out that the intermediate
calculations are done in enough precision to mask both the bugs and
the limited precision of the float variables (as far as ucbtest can
check).
ucbtest detects the bugs because it forces float precision, but this
is not a normal mode of operation so the bug normally has little effect
on i386's.
On systems that do float arithmetic in float precision, e.g., amd64's,
there is no accidental extra precision and the bugs just give wrong
results.
Reference: 12be4e0d5a
Original Author: Bruce Evans
The decomposition needs to be into 12+24 bits of precision for extra-
precision multiplication, but was into 13+24 bits. On i386 with -O1 the
bug was hidden by accidental extra precision, but on amd64, in 2^32
trials the bug caused about 200000 errors of more than 1 ulp, with a
maximum error of about 80 ulps. Now the maximum error in 2^32 trials
on amd64 is 0.8573 ulps. It is still 0.8316 ulps on i386 with -O1.
The nearby decomposition of 1/ln2 and the decomposition of 2/(3ln2) in
the double precision version seem to be sub-optimal but not broken.
Reference: b4437c3d32
Original Author: Bruce Evans
nl_langinfo_l accesses lc_messages_T::codeset as soon as
__HAVE_LOCALE_INFO__ is defined, but codeset only exists
if __HAVE_LOCALE_INFO_EXTENDED__ is defined.
Fix this by defining lc_messages_T::codeset depending on
__HAVE_LOCALE_INFO__.
Fixes: ac7f1d5e93 ("Get rid of LCID, reformat type definitions in setlocale.h")
Reported-by: Inglis <Brian.Inglis@SystematicSW.ab.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
The nl_ext array contains offsets into the extended info of
locale structures, the index being equivalent to the nl_item
values in langinfo.h.
For the lc_messages_T struct, nl_ext erroneusly contains an
entry for the codeset member, which is in fact not part of the
extended info in nl_item. However, due to that, the offsets for
subsequent entries are off by one.
Fix this by dropping the messages::codeset entry from nl_ext.
Fixes: d47d5b850b ("Extend locale support to maintain wide char values of native strings")
Reported-by: Brian Inglis <Brian.Inglis@systematicsw.ab.ca>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Synopsys ARCv3 ISA includes 32-bit ARC HS5x targets and
64-bit ARC HS6x targets. Both CPU families are placed
in "arc64" subdirectories as it done for GCC port.
Target name arc64 is used for historical reasons and
Synopsys ARCv3 baremetal toolchains contain multilib
configurations both for 32-bit and 64-bit families.
arc32 target name is reserved for 32-bit ARC HS5x
targets in case of non-multilib 32-bit builds.
Note that libgloss libraries for ARCv3 are compatible with
libgloss for ARCv1/2. Thus, Makefile.inc for libgloss uses
sources from libgloss/arc directory except crtX.S files.
Co-authored-by: Shahab Vahedi <list@vahedi.org>
Co-authored-by: Claudiu Zissulescu <claziss@gmail.com>
Co-authored-by: Bruno Mauricio <brunoasmauricio@gmail.com>
Co-authored-by: Luis Silva <luis.m.silva99@hotmail.com>
Signed-off-by: Yuriy Kolerov <ykolerov@synopsys.com>
This variable was accidentally renamed earlier. It must be
ldflags according to DejaGNU documentation.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
There's no semantic change, it's only to make the same code
compilable with MetaWare toolchian, which actually assumes
@x as a full name, not omitting @.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Replace __ARC_ALIGNED_ACCESS__ macro with the compiler defined
macro __ARC_UNALIGNED__ and improve file comments.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
This avoids a `__utoa undefined' warning when building newlib
for Cygwin. We still need to export the symbols for backward
compatibility.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
For RISC-V, AArch64, i386, and x86_64
- k_tanl.c is required for tanl; the linker will report `__kernel_tanl`
not found when tanl is called.
- s_cospil.c and s_sinpil.c are added for cospil and sinpil, which are already
available for ld80 but not for ld128.
This file was from a specific older FreeBSD version. There have been
multiple changes to this file with FreeBSD 14 including breaking
changes to the file. Including this file as part of newlib results
in not always having the correct version of sys/tree.h for any
specific software. RTEMS will manage its use of this file outside
of newlib.
The modifications added by the series "M-profile PACBTI-enablement"
(see 9d6b00511e) have introduced a couple
of .cfi_* instructions.
Like for e6459123e4, these instructions
create object files which contain .eh_frame sections. However, ARM uses
its own unwind info format, not .eh_frame, which is generated by
ARM-specific directives, not .cfi_*. The .eh_frame sections are useless,
but also not removed by strip and may be harmful with some linker
scripts.
Adding ".cfi_sections .debug_frame" (as in glibc) moves the generated
directives towards .debug_frame instead of .eh_frame. Making them easier
to handle.
* libc/machine/arm/aeabi_memmove-thumb2.S: Use .cfi_sections
.debug_frame.
* libc/machine/arm/aeabi_memset-thumb2.S: Likewise.
* libc/machine/arm/memchr.S: Likewise.
* libc/machine/arm/memcpy-armv7m.S: Likewise.
* libc/machine/arm/setjmp.S: Likewise.
* libc/machine/arm/strlen-armv7.S: Likewise.
* libc/machine/arm/strlen-thumb2-Os.S: Likewise.
The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.
Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix
Use of stdatomic.h is undefined in C++, even the C++ 2020 standard does not
list stdatomic.h as a C library header supported by the language. More,
there are some subtle differences between the <atomic> C++ header, and
C11+ stdatomic.h provided features.
Nonetheless, it is a quality of the implementation aspect, so let mis-users
mis-use stdatomic.h as they want, by making a compat shim for _Bool.
PR: 262683
Reported by: yuri
Reviewed by: dim, emaste
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D34686
Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
The vfma.f32|64 z, x, y instruction performs the operation
z += x * y without intermediate rounding.
The register used for z is both read and written by the instruction.
The inline assembly must therefore use the "+" constraint modifier.
The SuperH target doesn't build on GCC 14.1 because of missing
function prototypes or because some function declarations use the
deprecated K&R style. This patch adds missing prototypes on the files
the functions are used and convert K&R declarations to ANSI-style.
Signed-off-by: Pietro Monteiro <pietro@sociotechnical.xyz>
The linker needs to know whether a symbol is STT_FUNCTION when
deciding which farcall stub to emit (if needed), this patch adds this
to the FUNC_START macro which is used in crt0.
The rest of "long double" functions aren't compiled with long double
and double are not the same. Do the same for all complex functions.
Signed-off-by: Pietro Monteiro <pietro@sociotechnical.xyz>
The "longjmp" expects the "setjmp" to save the r58/r59 registers,
if there is any. With this change they are saved accordingly.
Checked for regression with running GCC's DejaGnu tests:
$ runtest execute.exp=pr56982.c dg-torture.exp=pr48542.c
Signed-off-by: Shahab Vahedi <shahab@synopsys.com>
Assembler for ARCv2 always extends the name provided by
.file directive to an absolute form.
On ARCv3 targets .file directive forces assembler to put
a provided string to DW_AT_name field as is without
extending to an absolute path. Then GDB cannot find
source files because of it.
The best way to fix this issue is just delete lines
with .file directive in .S files and let the compiler
to decide what DW_AT_name must contain. Particularly,
the compiler fills this filed by an absolute path to
a .S file because only absolute paths are used in
toolchain's build process.
Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>
ARC supports a restricted register file with 16 registers.
However, optimized routines support only a full register
file. Thus, fallback on default implementation in case
of 16-entry register file.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
As of commit 7dd4eb1db9
"amdgcn: Implement proper locks", we get, by the thousands, for C++ code:
In file included from [...]/newlib/libc/include/stdio.h:60,
from [...]:
[...]/newlib/libc/include/sys/reent.h:911:1: error: expected declaration before '}' token
This should prevent printf output from multiple threads getting garbled.
I don't know why IO ever worked properly -- probably it was always a bit
broken -- but the GFX11 devices have a different cache architecture and
trying to print from many threads at once corrupted the FILE buffers.
Regression tested in basepoints/gcc-14-9032-g945cb8490cb with arm-none-eabi.
Example failure without this change:
$ arm-none-eabi-g++ .../pr100611.C -std=c++20 --specs=nosys.specs -o /dev/null --specs=nano.specs
.../ld: .../libc_nano.a(libc_a-svfwprintf.o): in function `_svfwprintf_r':
(.text._svfwprintf_r+0xd8): undefined reference to `__ssputws_r'
.../ld: (.text._svfwprintf_r+0x834): undefined reference to `__ssputws_r'
.../ld: (.text._svfwprintf_r+0x85c): undefined reference to `__ssputws_r'
.../ld: (.text._svfwprintf_r+0x8a8): undefined reference to `__ssputws_r'
.../ld: (.text._svfwprintf_r+0x8dc): undefined reference to `__ssputws_r'
.../ld: .../libc_nano.a(libc_a-svfwprintf.o):(.text._svfwprintf_r+0x900): more undefined references to `__ssputws_r' follow
collect2: error: ld returned 1 exit status
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Co-authored-by: Yvan ROUX <yvan.roux@foss.st.com>
This fixes the following build issue:
newlib/libc/include/dirent.h:84:1: error: unknown type name 'ssize_t'; did you mean '_ssize_t'?
84 | ssize_t posix_getdents(int, void *, size_t, int);
| ^~~~~~~
| _ssize_t
The new _MB_CAPABALE-only _misc_reent member getlocalename_l_buf was
incorrectly initialized in the _REENT_INIT_MISC macro, so the build
failed for _REENT_SMALL targets, independet of the _MB_CAPABALE setting.
Fixes: 71511d4ac8 ("getlocalename_l: implement per SUS Base Specifications Issue 8 draft")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Lenard Mollenkopf
Fabian Schriever
Jeff Johnston
yang.zhang
Alexey Lapshin
Corinna Vinschen
Yuriy Kolerov
Claudiu Zissulescu
Alexey Brodkin
Jordi Sanfeliu
Joel Sherrill
Kito Cheng
Clément Chigot
Warner Losh
Konstantin Belousov
Pedro F. Giffuni
Mickaël Thomas
Pietro Monteiro
Christophe Lyon
Shahab Vahedi
Yuriy Kolerov
Thomas Schwinge
Andrew Stubbs
Chris Johns
Torbjörn SVENSSON
Christian Franke
Sebastian Huber