This patch is for the sake of gnulib.
gnulib implements some form of a thread-safe setlocale variant
called setlocale_null_r, which is supposed to return the locale
strings in a thread-safe manner. This only succeeds if the system's
setlocale already handles this thread-safe, otherwise gnulib adds
some locking on its own.
Newlib's setlocale always writes the global string array holding the
LC_ALL value anew on each invocation of setlocale(LC_ALL, NULL).
Since that doesn't allow to call setlocale(LC_ALL, NULL) in a
thread-safe manner, so locking in gnulib is required.
And here's the problem...
The lock is decorated as dllexport when building for Cygwin. This
collides with the default behaviour of ld to export all symbols.
If it finds one decorated symbol, it will only export this symbol
to the DLL import lib.
Change setlocale so that it writes the global string array
holding the LC_ALL value at the time the locale gets changed.
On setlocale(LC_ALL, NULL), just return the pointer to the
global LC_ALL string array, just as in GLibc. The burden of
doing so is negligibly for all targets, but adds thread-safety
for gnulib's setlocal_null_r() function, and gnulib can drop
the lock entirely when building for Cygwin.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
When compiling Newlib for arm targets with GCC 12.1 onward, the
passing of architecture extension information to the assembler is
automatic, making the use of .fpu and .arch_extension directives
in assembly files redundant.
With older versions of GCC, however, these directives must be
hard-coded into the `arm/setjmp.S' file to allow the assembly of
instructions concerning the storage and subsequent reloading of the
floating point registers to/from the jump buffer, respectively.
This patch conditionally adds the `.fpu vfpxd' and `.arch_extension
mve' directives based on compile-time preprocessor macros concerning
GCC version and target architectural features, such that both the
assembly and linking of setjmp.S succeeds for older versions of
Newlib.
We don't have floating-point exception or non-default rounding mode
support for the RISC-V soft-float environment, `feraiseexcept' and
`fesetround' do nothing unless the `__riscv_flen' macro has been set.
Therefore following ISO C language requirements[1] only define macros
for soft float that correspond to actually supported floating-point
environment features, removing failures from GCC testing such as:
FAIL: gcc.dg/torture/fp-int-convert-timode-3.c -O0 execution test
FAIL: gcc.dg/torture/fp-int-convert-timode-4.c -O0 execution test
References:
[1] "Programming languages -- C", ISO/IEC 9899:2023, working draft --
September 3, 2022, Section 7.6 "Floating-point environment <fenv.h>"
Fixes: 7040b2de08 ("Add RISC-V port for libm")
Signed-off-by: Maciej W. Rozycki <macro@embecosm.com>
This is still not properly resolving <https://gcc.gnu.org/PR85463>
'[nvptx] "exit" in offloaded region doesn't terminate process', but is
one step into that direction, and allows for simplifying some GCC code.
... as implemented for GCN in 'newlib/libc/sys/amdgcn/*' files, but (for now)
still adding to the catch-all 'newlib/libc/machine/nvptx/misc.c' file.
This is necessary for the GCC/Fortran I/O system, for example.
Co-authored-by: Andrew Stubbs <ams@codesourcery.com>
Such a hard-coded ELIX level restriction is only being applied for nvptx
newlib -- but we'd actually like higher levels' functions available there,
too. (Users continue to be able to override this via newlib 'configure',
as for every other newlib target.)
This already enables GCC test cases that currently FAIL due to
'unresolved symbol strndup' ('gcc.dg/builtin-dynamic-object-size-0.c'), or
'unresolved symbol mempcpy' ('gcc.dg/torture/pr45636.c'), for example.
Co-authored-by: Andrew Stubbs <ams@codesourcery.com>
Given that nvptx newlib currently restricts itself to ELIX level 1, this
is not already a problem. However, in the following we'd like to lift
that restriction, and then run into:
[...]/newlib/libc/ssp/stack_protector.c: In function ‘__stack_chk_init’:
[...]/newlib/libc/ssp/stack_protector.c:31:1: sorry, unimplemented: global constructors not supported on this target
31 | }
| ^
GCC patch "nvptx: Support global constructors/destructors via 'collect2'"
has been posted, but not yet accepted. Until that is resolved, use the
same manual SSP setup as for GCN.
This implements a set of vectorized math routines to be used by the
compiler auto-vectorizer. Versions for vectors with 2 lanes up to
64 lanes (in powers of 2) are provided.
These routines are based on the scalar versions of the math routines in
libm/common, libm/math and libm/mathfp. They make extensive use of the GCC
C vector extensions and GCN-specific builtins in GCC.
The libgloss port has been reaching back into newlib internals for a
single header whose contents have been frozen for almost a decade.
To break this backwards libgloss->newlib dependency, move the acle
header to the srcroot include/ so everyone can use the same copy.
Add function prologue/epilogue to conditionally add BTI landing pads
and/or PAC code generation & authentication instructions depending on
compilation flags. Save the PAC value in the jump buffer so that
longjmp can only return to the authenticated location.
Add function prologue/epilogue to conditionally add BTI landing pads
and/or PAC code generation & authentication instructions depending on
compilation flags.
This patch enables PACBTI for all relevant variants of strlen:
* Newlib for armv8.1-m.main+pacbti
* Newlib for armv8.1-m.main+pacbti+mve
* Newlib-nano
Add function prologue/epilogue to conditionally add BTI landing pads
and/or PAC code generation & authentication instructions depending on
compilation flags.
This patch enables PACBTI for all relevant variants of strcmp:
* Newlib for armv8.1-m.main+pacbti
* Newlib for armv8.1-m.main+pacbti+mve
* Newlib-nano
Augment the arm_asm.h header file to simplify function prologues and
epilogues whilst adding support for PACBTI enablement via macros for
hand-written assembly functions. For PACBTI, both prologues/epilogues
as well as cfi-related directives are automatically amended
accordingly, depending on the compile-time mbranch-protection argument
values.
It defines the following preprocessor macros:
* HAVE_PAC_LEAF: Indicates whether pac-signing has been requested for
leaf functions.
* PAC_LEAF_PUSH_IP: Whether leaf functions should push the pac code
to the stack irrespective of whether the ip register is clobbered in
the function or not.
* STACK_ALIGN_ENFORCE: Whether a dummy register should be added to
the push list as necessary in the prologue to ensure stack
alignment preservation at the start of assembly function. The
epilogue behavior is likewise affected by this flag, ensuring any
pushed dummy registers also get popped on function return.
It also defines the following assembler macros:
* prologue: In addition to pushing any callee-saved registers onto
the stack, it generates any requested pacbti instructions.
Pushed registers are specified via the optional `first', `last',
`push_ip' and `push_lr' macro argument parameters.
when a single register number is provided, it pushes that
register. When two register numbers are provided, they specify a
rage to save. If push_ip and/or push_lr are non-zero, the
respective registers are also saved. Stack alignment is requested
via the `align` argument, which defaults to the value of
STACK_ALIGN_ENFORCE, unless manually overridden.
For example:
prologue push_ip=1 -> push {ip}
prologue push_ip=1, align8=1 -> push {r2, ip}
prologue push_ip=1, push_lr=1 -> push {ip, lr}
prologue 1 -> push {r1}
prologue 1, align8=1 -> push {r0, r1}
prologue 1 push_ip=1 -> push {r1, ip}
prologue 1 4 -> push {r1-r4}
prologue 1 4 push_ip=1 -> push {r1-r4, ip}
* epilogue: pops registers off the stack and emits pac key signing
instruction, if requested. The `first', `last', `push_ip',
`push_lr' and `align' function as per the prologue macro,
generating pop instead of push instructions.
Stack alignment is enforced via the following helper macro
call-chain:
{prologue|epilogue} ->_align8 -> _preprocess_reglist ->
_preprocess_reglist1 -> {_prologue|_epilogue}
Finally, the necessary cfi directives for adding debug information
to prologue and epilogue are generated via the following macros:
* cfisavelist - prologue macro helper function, generating
necessary .cfi_offset directives associated with push instruction.
Therefore, the net effect of calling `prologue 1 2 push_ip=1' is
to generate the following:
push {r1-r2, ip}
.cfi_adjust_cfa_offset 12
.cfi_offset 143, -4
.cfi_offset 2, -8
.cfi_offset 1, -12
* cfirestorelist - epilogue macro helper function, emitting
.cfi_restore instructions prior to resetting the cfa offset. As
such, calling `epilogue 1 2 push_ip=1' will produce:
pop {r1-r2, ip}
.cfi_register 143, 12
.cfi_restore 2
.cfi_restore 1
.cfi_def_cfa_offset 0
... so that all of 'exit', '_exit', '_Exit' work. 'exit' thus becomes the
standard 'newlib/libc/stdlib/exit.c' -- and functions registered via 'atexit'
are now called at return from 'main' or manual 'exit' invocation.
It seems there is a swapped logic in one of the subcases of
setjmp.S for MIPS: when the FPU registers are 64-bit within
a 32-bit aligned jmp_buf, the code realigns the pointers
before doing 64-bit writes, but the branch logic is swapped:
we must avoid the address adjustement when bit 2 is zero
(that is, the address is already 8-byte aligned).
This always triggers an address error when run, as tested
on a MIPS VR4300 with O64 ABI.
The implementation of expf() explains how approximation in the range [0 - 0.34] is done. The comment describes the "Reme" algorithm for constructing the polynomial. This is a typo and should be the "Remez" algorithm. The remez algorithm (or minimax) is used to calculate the coefficients of polynomials in other implementations of exp(0 and log().
See more:
https://en.wikipedia.org/wiki/Remez_algorithm
This implements a set of vectorized math routines to be used by the
compiler auto-vectorizer. Versions for vectors with 2 lanes up to
64 lanes (in powers of 2) are provided.
These routines are based on the scalar versions of the math routines in
libm/common, libm/math and libm/mathfp. They make extensive use of the GCC
C vector extensions and GCN-specific builtins in GCC.
As per the arm Procedure Call Standard for the Arm Architecture
section 6.1.2 [1], VFP registers s16-s31 (d8-d15, q4-q7) must be
preserved across subroutine calls.
The current setjmp/longjmp implementations preserve only the core
registers, with the jump buffer size too small to store the required
co-processor registers.
In accordance with the C Library ABI for the Arm Architecture
section 6.11 [2], this patch sets _JBTYPE to long long adjusting
_JBLEN to 20.
It also emits vfp load/store instructions depending on architectural
support, predicated at compile time on ACLE feature-test macros.
[1] https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst
[2] https://github.com/ARM-software/abi-aa/blob/main/clibabi32/clibabi32.rst
We have "Iconv" and "iconv" nodes which generates Iconv.html and
iconv.html files. On a case-insensitive filesystem, these collide.
Rename the "Iconv" node to match the chapter name that it's already
using to avoid the issue.
Until Cygwin 3.3.6, we define __LARGE64_FILES unconditionally, so we
were using the type __sFILE64 even for 64 bit. That was lazy and wrong.
so commit 2902b3a09e ("Cygwin: drop requirement to build newlib's
stdio64") tried to fix that.
Unfortunately this patch forgot to take the exposure of the typename
__sFILE64 in userspace into account. This leads to trouble in C++ due
to name mangling.
Commit 0f376ae220 tried to fix this by just renaming __sFILE to
__sFILE64 by using a macro. While __sFILE and __sFILE64 are the same
size, they are not exactly congruent.
To avoid backward compatibility problems, make sure to define FILE
as the real __sFILE64, and make sure that __sFILE is not defined at
all on Cygwin.
Fixes: 0f376ae220 ("Cygwin: rename __sFILE to __sFILE64 for backward
compatibility")
Fixes: 2902b3a09e ("Cygwin: drop requirement to build newlib's stdio64")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
This patch fixes warnings that appears when compiling:
#define fwopen(__cookie,__fn) funopen(__cookie, (int (*)())0, __fn,
(fpos_t (*)())0, (int (*)())0)
Expands to:
funopen(__null, (int (*)())0, &app_printf, (fpos_t (*)())0, (int
(*)())0)
argument of type "int (*)()" is incompatible with parameter of type
"int (*)(void *__cookie, char *__buf, int __n)"C/C++(167)
invalid conversion from 'fpos_t (*)()' {aka 'long int (*)()'} to
'fpos_t (*)(void*, fpos_t, int)' {aka 'long int (*)(void*,
Discussion is here:
https://github.com/espressif/arduino-esp32/issues/7407
https://cygwin.com/pipermail/cygwin/2022-December/252571.html
Cygwin's default locale is "C.UTF-8" as far as LC_CTYPE settings
are concerned. However, while __global_locale contains fixed
mbtowc and wctomb pointers, the lc_ctype_T pointer is still pointing
to _C_ctype_locale, representing the standard "C" locale.
The problem with this is that the codeset name as well as MB_CUR_MAX
is wrong.
Fix this by introducing a new lc_ctype_T structure called
_C_utf8_ctype_locale, setting the default codeset to "UTF-8" and
MB_CUR_MAX to 6. Use this as lc_ctype_T pointer in __global_locale
by default on Cygwin.
Fixes: a6a477fa81 ("POSIX-1.2008 per-thread locales, groundwork part 1")
Co-Authored-By: Takashi Yano <takashi.yano@nifty.ne.jp>
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Call __builtin_gcn_get_stack_limit and __builtin_gcn_first_call_this_thread_p
to reduce dependency on some register/layout assumptions by using the new
GCC mainline (GCC 13) builtins, if they are available. If not, the existing
code is used.
During 'make man', makedocbook falsely reports "texinfo command
'@modifier' remains in output" while processing the setlocal(3) manpage,
which contains that literal string.
Move the check for unrecognized texinfo commands to before processing
'@@' (an escaped '@') in the texinfo source, and teach it to ignore
them.
Improve that check slightly, so it catches non-alphabetic texinfo
commands, of which there are few.
Now we don't have false positives, we can make unrecognized texinfo
commands fatal to manpage generation, rather than leaving them verbatim
in the generated manpage.
..., not just '#if defined(__CYGWIN__)'. (Exception: 'clog10l' which currently
indeed is for Cygwin only.)
This completes 2017-07-05 commit be3ca39474
"Fixed warnings for some long double complex methods" after Aditya Upadhyay's
work on importing "Long double complex methods" from NetBSD.
For example, this changes GCC/nvptx libgfortran 'configure' output as follows:
[...]
checking for ccosf... yes
checking for ccos... yes
checking for ccosl... [-no-]{+yes+}
[...]
..., and correspondingly GCC/nvptx 'nvptx-none/libgfortran/config.h' as
follows:
[...]
/* Define to 1 if you have the `ccosl' function. */
-/* #undef HAVE_CCOSL */
+#define HAVE_CCOSL 1
[...]
Similarly for 'ccoshl', 'cexpl', 'cpowl', 'csinl', 'csinhl', 'ctanl', 'ctanhl',
'cacoshl', 'cacosl', 'casinhl', 'catanhl'. ('conjl', 'cprojl' are not
currently being used in libgfortran.)
This in turn simplifies GCC/nvptx 'libgfortran/intrinsics/c99_functions.c'
compilation such that this files doesn't have to provide its own
"Implementation of various C99 functions" for those, when in fact they're
available in newlib libm.
Commit 737e2004a3 accidentally introduced a call to strlen in
code used with wide character strings in case of wcsftime. Use
STRLEN instead.
Fixes: 737e2004a3 ("strftime.c(__strftime): add %q, %v, tests; tweak %Z doc")
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Drop 'makedocbook --cache' (any dependency on the man-cache rule which
invokes that was dropped by the non-recursive make changes)
Instead, add some explicit locking which prevents processes colliding
over the file containing generated python code for the parser table.
The first attempt to support the 64-bit mode had two bugs:
1. The saved general-purpose register 31 value was overwritten with the saved
link register value.
2. The link register was saved and restored using 32-bit instructions.
Use 64-bit store/load instructions to save/restore the link register. Make
sure that the general-purpose register 31 and the link register storage areas
do not overlap.
> ERROR: xref linking to Stubs has no generated link text.
> Error: no ID for constraint linkend: Stubs.
(Despite saying "ERROR", this is actually a warning, and manpages are
still generated)
Improve chapter-texi2docbook so it generates elements for texinfo
sections as well, so that a cross-reference to the "Stubs" section
contains a valid element ID.
Corinna Vinschen
Victor L. Do Nascimento
Maciej W. Rozycki
Jeff Johnston
Thomas Schwinge
Sebastian Huber
Kwok Cheung Yeung
Mike Frysinger
CompilerAI Research Group
Giovanni Bajo
Nadav Rotem
Alexey Lapshin
Tobias Burnus
Jon Turney
Brian Inglis