The code accessing the floating point control/status register, namely
#define __cfc1(__fcsr) __asm __volatile("cfc1 %0, $31" : "=r" (__fcsr)
does not compile with mips16. This changed the makefile to pass -mno-mips16 to avoid the following
compiler error:
mips-mti-elf fails with "Error: unrecognized opcode `cfc1 $3,$31'"
- Currently, printf("%La\n", 1e1000L) crashes with segv due to lack
of frexpl() function. With this patch, frexpl() function has been
implemented in libm to solve this issue.
Addresses: https://sourceware.org/pipermail/newlib/2021/018718.html
- If the number has large integer part and small fraction part is
specified in output format, e.g. printf("%.3f", sqrt(2)*1e60);,
valid output digits were insufficient. This patch fixes the issue.
https://cygwin.com/pipermail/cygwin/2021-November/249930.html
reported a regression introduce by using a dynamically sized local
char array in favor of a statically sized array.
Fix this by reverting to a statically sized array, using a small
buffer on the stack for a reasonable number of requested digits, a
big mallocated buffer otherwise. This should work for small targets
as well, given that malloc is used in printf anyway right now.
This is *still* hopefully just a temporary measure, unless somebody
actually provides a new ldtoa.
Fixes: 4d90e53359 ("ldtoa: fix dropping too many digits from output")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Use the same name as glibc & gnulib to indicate "newlib itself is
being compiled". This also harmonizes the codebase a bit in that
_LIBC was already used in places instead of _COMPILING_NEWLIB.
Building for bfin-elf, mips-elf, and x86_64-pc-cygwin produces
the same object code.
Some distros enable _FORTIFY_SOURCE by default which upsets building
newlib which itself implements the logic for this define. For example,
building gets.c fails because the includes set up a gets() macro which
expands in the definition.
Since newlib isn't prepared to build itself with _FORTIFY_SOURCE, and
it's not clear if it's even useful, ignore it when building the code.
This also matches what glibc is doing.
The _COMPILING_NEWLIB symbol is for declaring "the code is being
compiled for newlib itself" so headers can change behavior vs the
header being used by users (who should get the normal clean API).
Unfortunately, this symbol is defined inconsistently leading to it
only being useful for a few subsections of the tree.
Pull it out so that it's defined all the time for all targets.
We're seeing a build failure in GNU sim code which is using _P locally
but the ctype.h define clashes with it. Rename these to use the same
symbols that glibc does. They're a bit more verbose, but seems likely
that we'll have fewer conflicts if glibc isn't seeing them.
However, these shortnames are still used internally by ctype modules
to produce pretty concise source code, so move the short names to the
internal ctype_.h where short name conflicts shouldn't show up.
This code looks like it's written to be copied & pasted between diff
C libraries and relies on _LIBC only being used with glibc. This will
break when newlib changes from _COMPILING_NEWLIB to _LIBC, so delete
the glibc-specific logic ahead of time.
ldtoa cuts the number of digits it returns based on a computation of
number of supported bits (144) divide by log10(2). Not only is the
integer approximation of log10(2) ~= 8/27 missing a digit here, it
also fails to take really small double and long double values into
account.
Allow for the full potential precision of long double values. At the
same time, change the local string array allocation to request only as
much bytes as necessary to support the caller-requested number of
digits, to keep the stack size low on small targets.
In the long run a better fix would be to switch to gdtoa, as the BSD
variants, as well as Mingw64 do.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Currently, newlib does not declare strsignal if DEFS_H is defined,
ostensibly to work around a gdb bug. However, gdb itself compiles
even with this ifndef removed, and this makes sim (another part of
gdb) fail to compile.
Since it is not clear exactly what issue this was working around,
this patch just replaces that ifdef with the correct check,
i.e. __POSIX_VISIBLE >= 200809.
Reported by prodisDown:
In picolibc/newlib/libc/string/strrchr.c
if (i) { while ((s=strchr(s, i))) { last = s; s++; } } else { last = strchr(s, i); }
Value (for example 0xFFFFFF00) in if (i) can pass test and
then be typecasted to char inside strchr(). Then s++ and then
buffer overrun.
It can be fixed by preventive typecast i = (int) (char) i; or
typecasting inside expression if ((char) i).
Fixed by casting to char.
Signed-off-by: Keith Packard <keithp@keithp.com>
Add specialized rotations RB_RED_ROTATE_LEFT() and RB_RED_ROTATE_RIGHT() which
may be used if we rotate a red child which has a black sibling. Such a red
node must have at least two child nodes so that the following red-black tree
invariant is fulfilled:
Every path from a given node to any of its descendant NULL nodes goes through
the same number of black nodes.
PARENT
/ \
BLACK RED
/ \
BLACK BLACK
Add specialized rotations RB_PARENT_ROTATE_LEFT() and RB_PARENT_ROTATE_RIGHT()
which may be used if the parent node exists and the direction of the child is
known. The specialized rotations are derived from RB_ROTATE_LEFT() and
RB_ROTATE_RIGHT() where the RB_SWAP_CHILD() was replaced by a simple
assignment.
In RB_GENERATE_REMOVE_COLOR() simplify a chain of conditions of the following
pattern
if (x) {
...
} else if (!x) {
...
}
to
if (x) {
...
} else {
...
}
We have
#define RB_ISRED(elm, field) \
((elm) != NULL && RB_COLOR(elm, field) == RB_RED)
So, the RB_ISRED() contains an implicit check for NULL. In
RB_GENERATE_REMOVE_COLOR() the "elm" pointer cannot be NULL in the while
condition. Use RB_COLOR(elm) == RB_BLACK instead.
There are a few files that are tied to the GNU simulator, so add myself
to match the general sim project.
Also add myself to the general write-after-approval since I've been doing
that for a long time now anyways :).
When newlib is configured with --enable-newlib-reent-check-verify,
the assert macro is already defined in the nano-mallocr.c compile unit.
Contributed by STMicroelectronics
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@st.com>
libm/machine/i386/f_ldexp.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild'
libm/machine/i386/f_ldexpf.S:30: Warning: no instruction mnemonic suffix given and no register operands; using default for `fild'
fix this by adding the l mnemonic suffix
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
unused function warning for two_way_short_needle,
different char type warnings for standard string functions
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
_STDIO_WITH_THREAD_CANCELLATION_SUPPORT was never defined.
Include ../stdio/local.h to get the right definition per target.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
__STDINT_EXP() is provided by newlib but not by stdint-gcc.h. stdint-gcc.h
is used when the GCC argument -ffreestanding is used and this results in this
file not compiling.
This patch to the libc/machine/nvptx port of newlib implements an
approximation of "clock" and provides some additional stub routines.
These changes not only reduce the number of (link) failures in the GCC
testsuite when targeting nvptx-none, but also allow the NIST scimark4
benchmark to compile and run without modification.
newlib already contains support for backends to provide their own
clock implementations via -DCLOCK_PROVIDED. That functionality is
used here to return an approximate elapsed time based on the NVidia
GPU's clock64 cycle counter. Although not great, this is better than
the current behaviour of link error from the unresolved symbol
_times_r.
The other part of the patch is to add a small number of stub functions
to nvptx's misc.c. Adding isatty, for example, resolves linking
problems in libc from the dependency in __smakebuf_r, and the sync
stub, for example, fixes the failure with GCC's
testsuite/gfortran.dg/ISO_Fortran_binding_14.f90 [which simply tests
that gfortran can call a/any C function].
newlib/
configure.host: Add -DCLOCK_PROVIDED to newlib_cflags on nvptx*.
newlib/libc/machine/nvptx
Makefile.am: Add clock.c to lib_a_SOURCES.
clock.c: New source file to implement/approximate clock().
misc.c: Add stubs for fstat, isatty, open, sync and unlink.
_strtod_l as well as the gethex function both fetch the decimal point
from the current LC_NUMERIC locale info. This pulls in _C_numeric_locale
unconditionally even on targets not supporting locales at all.
Another problem is that strtod.c and gdtoa-gethex.c are ELIX 1, while
locale information in general isn't. This leads to potential build
breakage on bare metal targets.
Fix this by setting the decimal point to "." on all targets not
defining __HAVE_LOCALE_INFO__.
While at it, const'ify the entire local decimal point info in the
affected functions.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
svfwscanf replaces getwc and ungetwc_r. The comments in the code talk
about avoiding file operations, but they also need to bypass the
mbtowc calls as svfwscanf operates on wchar_t, not multibyte data,
which is a more important reason here; they would not work correctly
otherwise.
The ungetwc replacement has code which uses the 3 byte FILE _ubuf
field, but if wchar_t is 32-bits, this field is not large enough to
hold even one wchar_t value. Building in this mode generates warnings
about array overflow:
In file included from ../../newlib/libc/stdio/svfiwscanf.c:35:
../../newlib/libc/stdio/vfwscanf.c: In function '_sungetwc_r.isra':
../../newlib/libc/stdio/vfwscanf.c:316:12: warning: array subscript 4294967295 is above array bounds of 'unsigned char[3]' [-Warray-bounds]
316 | fp->_p = &fp->_ubuf[sizeof (fp->_ubuf) - sizeof (wchar_t)];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../newlib/libc/stdio/stdio.h:46,
from ../../newlib/libc/stdio/vfwscanf.c:82,
from ../../newlib/libc/stdio/svfiwscanf.c:35:
../../newlib/libc/include/sys/reent.h:216:17: note: while referencing '_ubuf'
216 | unsigned char _ubuf[3]; /* guarantee an ungetc() buffer */
| ^~~~~
However, the vfwscanf code *never* ungets data before the start of the
scanning operation, and *always* ungets data which matches the input
at that point, so the code always hits the block which backs up over
the input data and never hits the block which uses the _ubuf field.
In addition, the svfwscanf code will always start with the unget
buffer empty, so the ungetwc replacement never needs to support an
unget buffer at all.
Simplify the code by removing support for everything other than
backing up over the input data, leaving the check to make sure it
doesn't get underflowed in case the vfscanf code has a bug in it.
Signed-off-by: Keith Packard <keithp@keithp.com>
Added function prototypes to newlib/libc/include/pthread.h
for the following Issue 8 Standard APIs:
pthread_cond_clockwait()
pthread_mutex_clocklock()
pthread_rwlock_clockrdlock()
pthread_rwlock_clockwrlock()
A recent patch introduced new code for sig2str/str2sig.
This code does not properly exclude code that requires
SIGRTMIN/SIGRTMAX to be defined and triggers the following
compile error:
newlib/libc/signal/sig2str.c:199:8: error: 'SIGRTMIN' undeclared
newlib/libc/signal/sig2str.c:200:29: error: 'SIGRTMAX' undeclared
Let's add the missing guards.
Fixes: 2b50ec0cd2 ("libc: Fix compilation for new sig2str/str2sig implementation")
Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>
Added implementations for sig2str() and str2sig() in libc/signal
in order to improve POSIX compliance. Added fucntion prototypes
in libc/include/sys/signal.h.
riscv64-unknown-elf-g++-11.1.0 regression suite reports the following
failures for
$ make check-gcc-c++ RUNTESTFLAGS='dg.exp=Wstringop-overflow-6.C'
```
FAIL: g++.dg/warn/Wstringop-overflow-6.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-6.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/warn/Wstringop-overflow-6.C -std=gnu++2a (test for excess errors)
UNSUPPORTED: g++.dg/warn/Wstringop-overflow-6.C -std=gnu++98
```
The "excess errors" being
```
output is In file included from /home/maxim/prj/riscv-upstream/install/riscv64-unknown-elf/include/wchar.h:6,
from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/cwchar:44,
from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/bits/postypes.h:40,
from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/iosfwd:40,
from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/ios:38,
from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/ostream:38,
from /home/maxim/prj/riscv-upstream/build/gcc-stage2/riscv64-unknown-elf/libstdc++-v3/include/iostream:39,
from /home/maxim/prj/riscv-upstream/gcc-11.1.0/gcc/testsuite/g++.dg/warn/Wstringop-overflow-6.C:6:
/home/maxim/prj/riscv-upstream/install/riscv64-unknown-elf/include/sys/reent.h:685:11: warning: unnecessary parentheses in declaration of '_sig_func' [-Wparentheses]
```
cc Aldy Hernandez <aldyh@redhat.com> and Andrew MacLeod <amacleod@redhat.com>,
they are author of new VRP analysis for GCC, just to make sure I didn't
mis-understanding or mis-interpreting anything on GCC site.
GCC 11 have better value range analysis, that give GCC more confidence
to perform more aggressive optimization, but it cause scalbn/scalbnf get
wrong result.
Using scalbn to demostrate what happened on GCC 11, see comments with VRP
prefix:
```c
double scalbn (double x, int n)
{
/* VRP RESULT: n = [-INF, +INF] */
__int32_t k,hx,lx;
...
k = (hx&0x7ff00000)>>20;
/* VRP RESULT: k = [0, 2047] */
if (k==0) {
/* VRP RESULT: k = 0 */
...
k = ((hx&0x7ff00000)>>20) - 54;
if (n< -50000) return tiny*x; /*underflow*/
/* VRP RESULT: k = -54 */
}
/* VRP RESULT: k = [-54, 2047] */
if (k==0x7ff) return x+x; /* NaN or Inf */
/* VRP RESULT: k = [-54, 2046] */
k = k+n;
if (k > 0x7fe) return huge*copysign(huge,x); /* overflow */
/* VRP RESULT: k = [-INF, 2046] */
/* VRP RESULT: n = [-INF, 2100],
because k + n <= 0x7fe is false, so:
1. -INF < [-54, 2046] + n <= 0x7fe(2046) < INF
2. -INF < [-54, 2046] + n <= 2046 < INF
3. -INF < n <= 2046 - [-54, 2046] < INF
4. -INF < n <= [0, 2100] < INF
5. n = [-INF, 2100] */
if (k > 0) /* normal result */
{SET_HIGH_WORD(x,(hx&0x800fffff)|(k<<20)); return x;}
if (k <= -54) {
/* VRP OPT: Evaluate n > 50000 as true...*/
if (n > 50000) /* in case integer overflow in n+k */
return huge*copysign(huge,x); /*overflow*/
else return tiny*copysign(tiny,x); /*underflow*/
}
k += 54; /* subnormal result */
SET_HIGH_WORD(x,(hx&0x800fffff)|(k<<20));
return x*twom54;
}
```
However give the input n = INT32_MAX, k = k+n will overflow, and then we
expect got `huge*copysign(huge,x)`, but new VRP optimization think
`n > 50000` is never be true, so optimize that into `tiny*copysign(tiny,x)`.
so the solution here is to moving the overflow handle logic before `k = k + n`.
- GCC will set __FLT_EVAL_METHOD__ to 16 if __fp16 supported, e.g.
cortex-a55/aarch64.
- $ aarch64-unknown-elf-gcc -v 2>&1 |grep version
gcc version 9.2.0 (GCC)
- $ aarch64-unknown-elf-gcc -E -dM -mcpu=cortex-a55 - < /dev/null |grep FLT_EVAL_METHOD
#define __FLT_EVAL_METHOD__ 16
#define __FLT_EVAL_METHOD_TS_18661_3__ 16
#define __FLT_EVAL_METHOD_C99__ 16
- The behavior of __FLT_EVAL_METHOD__ == 16 is same as
__FLT_EVAL_METHOD__ == 0 except for float16_t, but newlib didn't
support float16_t.
ISO/IEC TS 18661-3:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2405.pdf
V2 Changes:
- List Howland, Craig D as co-author since he provide the draft of comment
in math.h.
Co-authored-by: "Howland, Craig D" <howland@LGSInnovations.com>
The C standard says that errno may acquire the value ERANGE if the
result from strtod underflows. According to IEEE 754, underflow occurs
whenever the value cannot be represented in normalized form.
Newlib is inconsistent in this, setting errno to ERANGE only if the
value underflows to zero, but not for denorm values, and never for hex
format floats.
This patch attempts to consistently set errno to ERANGE for all
'underflow' conditions, which is to say all values which are not
exactly zero and which cannot be represented in normalized form.
This matches glibc behavior, as well as the Linux, Mac OS X, OpenBSD,
FreeBSD and SunOS strtod man pages.
Signed-off-by: Keith Packard <keithp@keithp.com>
The scanf code was skipping the '0' after the 'x' causing the
resulting buffer to contain an invalid number when passed to strtod.
Signed-off-by: Keith Packard <keithp@keithp.com>
- compiler is sometimes optimizing out the rounding check in
e_sqrt.c and ef_sqrt.c which uses two constants to create
an inexact operation
- there is a similar constant operation in s_tanh.c/sf_tanh.c
- make the one and tiny constants volatile to stop this
Jeff Johnston
Takashi Yano
Corinna Vinschen
Jon Turney
Thomas Wolff
Mike Frysinger
Christian Biesinger via Newlib
Keith Packard
Sebastian Huber
Joel Sherrill
Roger Sayle
Matt Joyce
Christoph Muellner
Maxim Blinov
Alex White
Kito Cheng
Jonathan Wakely
Dimitar Dimitrov