The 'cygnus' option was removed from automake 1.13 in 2012, so the
presence of this option prevents that or a later version of automake
being used.
A check-list of the effects of '--cygnus' from the automake 1.12
documentation, and steps taken (where possible) to preserve those
effects (See also this thread [1] for discussion on that):
[1] https://lists.gnu.org/archive/html/bug-automake/2012-03/msg00048.html
1. The foreign strictness is implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
2. The options no-installinfo, no-dependencies and no-dist are implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
Future work: Remove no-dependencies and any explicit header dependencies,
and use automatic dependency tracking instead. Are there explicit rules
which are now redundant to removing no-installinfo and no-dist?
3. The macro AM_MAINTAINER_MODE is required.
Already present in newlib/acinclude.m4
Note that maintainer-mode is still disabled by default.
4. Info files are always created in the build directory, and not in the
source directory.
This appears to be an error in the automake documentation describing
'--cygnus' [2]. newlib's info files are generated in the source
directory, and no special steps are needed to keep doing that.
[2] https://lists.gnu.org/archive/html/bug-automake/2012-04/msg00028.html
5. texinfo.tex is not required if a Texinfo source file is specified.
(The assumption is that the file will be supplied, but in a place that
automake cannot find.)
This effect is overriden by an explicit setting of the TEXINFO_TEX
variable (the directory part of which is fed into texi2X via the
TEXINPUTS environment variable).
6. Certain tools will be searched for in the build tree as well as in the
user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.
For obscure automake reasons, this effect of '--cygnus' is not active
for makeinfo in newlib's configury.
However, there appears to be top-level configury which selects in-tree
runtest, expect and makeinfo, if present. So, if that works as it
appears, this effect is preserved. If not, this may cause problem if
anyone is building those tools in-tree.
This effect is not preserved for texi2dvi. This may cause problems if
anyone is building texinfo in-tree.
If needed, explicit checks for those tools looking in places relative to
$(top_srcdir)/../ as well as in PATH could be added.
7. The check target doesn't depend on all.
This effect is not preseved. The check target now depends on the all
target.
This concern seems somewhat academic given the current state of the
testsuite.
Also note that this doesn't touch libgloss.
Add all the effects of 'cygnus' for which there exists an explicit way
to request that behaviour:
* Implied foreign strictness and options no-installinfo, no-dependencies
and no-dist are added to AM_INIT_AUTOMAKE in newlib/acinclude.m4.
* macro AM_MAINTAINER_MODE is added to newlib/acinclude.m4.
* For the implied TEXINFO_TEX of '$(top_srcdir)/../texinfo/texinfo.tex',
an explicit TEXINFO_TEX is always relative to $(srcdir), so write the
same pathname in that form.
This is to prepare for the removal of the automake option '--cygnus'.
Use AM_SILENT_RULES, to enable automake silent rules (by default), if we
are using a version of automake which supports it (>=1.11).
Silent rules can be disabled by configuring with '--disable-silent-rules',
or invoking 'make V=1'.
For ease of reviewing, this patch doesn't contain configure and
Makefile.in regeneration.
Future work: There are a few compilations which are not silenced by
this, as they use custom rules.
- This patch uses gdtoa imported from OpenBSD if newlib configure
option "--enable-newlib-use-gdtoa=no" is NOT specified. gdtoa
provides more accurate output and faster conversion than legacy
ldtoa, while it requires more heap memory.
- Currently, frexpl() supports only the following cases.
1) LDBL_MANT_DIG == 64 or 113
2) 'long double' is equivalent to 'double'
This patch add support for LDBL_MANT_DIG == 53.
This patch fixed a problem which isn't in newlib, but in projects
incorrectly using symbols from the reserved namespace.
This reverts commit 3ba1bd0d9d.
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
Newlib for aarch64 uses libgloss for the backend. One common libgloss
implementation is the 'rdimon' implementation, which uses the Arm
Semihosting protocol. In order to support a remote host that runs on
Windows we need to know whether a file is to be opened in binary or
text mode. That means that we need to preserve this information via
O_BINARY until we know what the libgloss binding will be.
This patch simply copies the arm implementation from sys/arm/sys and
puts it in machine/aarch64/sys, because we don't have a 'sys' subtree
on aarch64.
The only reason why it is tough for us to use nano malloc
is because of the small shortcoming where nano_malloc()
splits a bigger chunk from the free list into two pieces
while handing back the second one (the tail) to the user.
This is error prone and especially bad for smaller heaps,
where nano malloc is supposed to be superior. The normal
malloc doesn't have this issue and we need to use it even
though it costs us ~2k bytes compared to nano-malloc.
The problem arise especially after giving back _every_
malloced memory to the heap and then starting to exercise
the heap again by allocating something small. This small
item might split the whole heap in two equally big parts
depending on how the heap has been exercised before.
I have uploaded the smallest possible application
(only tested on ST and Nordic devices) to show the issue
while the real customer applications are far more complicated:
https://drive.google.com/file/d/1kfSC2KOm3Os3mI7EBd-U0j63qVs8xMbt/view?usp=sharing
The application works like the following pseudo code,
where we assume a heap of 100 bytes
(I haven't taken padding and other nitty and gritty
details into account. Everything to simplify understanding):
void *ptr = malloc(52); // We get 52 bytes and we have
// 48 bytes to use.
free(ptr); // Hand back the 52 bytes to nano_malloc
// This is the magic line that shows the issue of
// nano_malloc
ptr = malloc(1); // Nano malloc will split the 52 bytes
// in the free list and hand you a pointer
// somewhere in the
// middle of the heap.
ptr2 = malloc(52); // Out of memory...
I have done a fix which hands back the first part of the
splitted chunk. Once this is fixed we obviously
have the 1 byte placed in position 0 of the heap instead
of somewhere in the middle.
However, this won't let us malloc 52 new bytes even though
we potentially have 99 bytes left to use in the heap. The
reason is that when we try to do the allocation,
nano-malloc looks into the free list and sees a 51 byte
chunk to be used.
This is not big enough so nano-malloc decides to call
sbrk for _another_ 52 bytes which is not possible since
there is only 48 bytes left to ask for.
The solution for this problem is to check if the last
item in the free list is adjacent to sbrk(0). If it is,
as it is in this case, we can just ask sbrk for the
remainder of what is needed. In this case 1 byte.
NB! I have only tested the solution on our ST device.
Use the more official fesetenv(FE_DFL_ENV) from _dll_crt0, thus
allowing to drop the _feinitialise declaration from fenv.h.
Provide a no-op _feinitialise in Cygwin as exportable symbol for really
old applications when _feinitialise was called from mainCRTStartup in
crt0.o.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Drop the Cygwin-specific fenv.cc and fenv.h file and use the equivalent
newlib functionality now, so we have at least one example of a user for
this new mechanism.
fenv.c: allow _feinitialise to be called from Cygwin startup code
fenv.h: add declarations for fegetprec and fesetprec for Cygwin only.
Fix a comment.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Add a directory libc/machine/shared_x86 to share header files
between ix86 and x86_64 architectures.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
So far the build mechanism in newlib only allowed to either define
machine-specific headers, or headers shared between all machines.
In some cases, architectures are sufficiently alike to share header
files between them, but not with other architectures. A good example
is ix86 vs. x86_64, which share certain traits with each other, but
not with other architectures.
Introduce a new configure variable called "shared_machine_dir". This
dir can then be used for headers shared between architectures.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Without this, for a bare-iron/simulator target such as cris-elf,
you'll see, at newlib build time:
/x/gccobj/./gcc/xgcc -B/x/gccobj/./gcc/ <many options elided> -c -o lib_a-aligned_alloc.o \
`test -f 'aligned_alloc.c' || echo '/y/newlib/libc/stdlib/'`aligned_alloc.c
/y/newlib/libc/stdlib/aligned_alloc.c: In function 'aligned_alloc':
/y/newlib/libc/stdlib/aligned_alloc.c:35:10: warning: implicit declaration of function \
'_memalign_r' [-Wimplicit-function-declaration]
35 | return _memalign_r (_REENT, align, size);
| ^~~~~~~~~~~
The revert-part of the revert-and-fix commit, b99887c428 a.k.a.
"Revert previous change to sys/stat.h and fix cris libgloss",
apparently intending to revert f75aa67851 a.k.a. "Fix regression in
cris-elf caused by sys/stat.h change" and fix it in another way,
wasn't complete. Although the fix-part added the prerequisite "#undef
st_atime" (et al) to gensyscalls, the revert-part didn't revert the
"&& !defined(__cris__)" in sys/stat.h, stopping st_atime (et al) from
being defined.
The effect of the unreverted change is that accessing the struct stat
compatibility member names "st_atime" (et al) as in "struct stat
mystat; mystat.st_atime;" yields errors, observable for example when
building libgfortran in gcc:
/x/gcc/libgfortran/intrinsics/stat.c:114:42: error: 'struct stat' has \
no member named 'st_atime'; did you mean 'st_atim'?
114 | sarray->base_addr[8 * stride] = sb.st_atime;
| ^~~~~~~~
| st_atim
(etc.)
Trivially fixed by completing the reversion, removing the "&&
!defined(__cris__)" in sys/stat.h.
Beware: the net effect of the earlier related change to struct stat in
sys/stat.h, leading up to the fix, *does* change its definition as a
type. Thankfully, replacing members like "time_t st_atime; long
st_spare1;" by "struct timespec st_atim;", ditto st_mtim and st_ctim,
is layout-compatible. To wit, that change is "binary compatible".
Incidentally, related to the simulator / Linux ABI, there's a
transitional stage (see gensyscalls), reloading between "struct stat"
(sys/stat.h) and "struct new_stat" (kernel/simulator) as necessary.
Tested by a cris-elf gcc build (including libgfortran).
This Patch removes Soft Float code from MIPS.
Instead It adds the soft float code from RISCV
The code came from FreeBSD and assumes the FreeBSD softfp
implementation not the one with GCC. That was an overlooked and
fixed in the other fenv code already.
Signed-off-by: Eshan Dhawan <eshandhawan51@gmail.com>
Change the prototypes to be in line with POSIX/glibc. This may fix
issues with new warnings produced by GCC 11.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Add the POSIX header file <poll.h> which is used by the GCC 11 Ada
runtime support.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The Cortex-R52 processor is an Armv8-R processor with a NEON unit. This
fix prevents conflicting architecture profiles A/R errors issued by the
linker.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
This patch fixes the error found by Paul Zimmermann (see
https://homepages.loria.fr/PZimmermann/papers/#accuracy) regarding x
close to 1 and rather large y (specifically he found the case
powf(0x1.ffffeep-1,-0x1.000002p+27) which returns +Inf instead of the
correct value). We found 2 more values for x which show the same faulty
behaviour, and all 3 are fixed with this patch. We have tested all
combinations for x in [+1.fffdfp-1, +1.00020p+0] and y in
[-1.000007p+27, -1.000002p+27] and [1.000002p+27,1.000007p+27].
The overflow check in mEMALIGn erroneously checks for INT_MAX,
albeit the input parameter is size_t. Fix this to check for
__SIZE_MAX__ instead. Also, it misses to check the req against
adding the alignment before calling mALLOc.
While at it, add out-of-bounds checks to pvALLOc, nano_memalign,
nano_valloc, and Cygwin's (unused) dlpvalloc.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Jon Turney
Takashi Yano
Corinna Vinschen
Jeff Johnston
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
Richard Earnshaw
Ola Olsson
Ties Stuij
David Macek
Marcus Comstedt
Hans-Peter Nilsson
Eshan dhawan
Paul Zimmermann
Fabian Schriever
Corinna Vinschen
Ivan Grokhotov