[PATCH] mcel-tests: fix read overrun in test case

* tests/test-mcel.c (main): Don’t overrun test input buffer. Problem reported by Bruno Haible; found on CHERI-64. --- ChangeLog | 6 ++ tests/test-mcel.c | 5 +++-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index bc9ed2e489..d322f9a08e 100644

fenv-exceptions-tracking-c99 tests: Fix typo

2023-11-06 Bruno Haible fenv-exceptions-tracking-c99 tests: Fix typo. Found by coverity. * tests/test-fenv-except-tracking-1.c (main): Write & ~, not & !. diff --git a/tests/test-fenv-except-tracking-1.c b/tests/test-fenv-except-tracking-1.c index b7f871e12b..79384499f

fenv-*: Port to OpenBSD/mips64

On OpenBSD/mips64, I see a couple of test failures of the fenv-* modules: FAIL: test-fenv-env-1 FAIL: test-fenv-env-2 FAIL: test-fenv-env-3 FAIL: test-fenv-env-4 FAIL: test-fenv-except-state-2 FAIL: test-fenv-except-tracking-2.sh FAIL: test-fenv-except-trapping-2.sh FAIL: test-fenv-round FAIL: tes

nan: Defeat clang's incorrect -O2 optimization on mips64

The previous patch was sufficient for clang without optimization. For "clang -O2", another patch is needed in order to prevent the wrong NaNf(), NaNl() results. 2023-11-06 Bruno Haible nan: Defeat clang's incorrect -O2 optimization on mips64. * lib/nan.h (NaNf, NaNd, NaNl): Us

nan: Work around clang's incorrect constant-folding on mips64

Since the quiet NaN and signalling NaN representation on mips depends on the CPU model, it can be expected that a compiler guesses it wrong. This means: - The compiler's constant-folding of 0.0f/0.0f, 0.0/0.0, 0.0L/0.0L produces a signalling NaN instead of quiet NaN. (This is the case on

snan: Add more info for mips-based platforms

While porting the fenv* modules to OpenBSD/mips64, I noticed some test failures in the 'nan' and 'snan' tests: FAIL: test-nan-1 ../../gltests/test-nan-1.c:65: assertion '!fetestexcept (FE_INVALID)' failed Abort trap (core dumped) FAIL test-nan-1 (exit status: 134) FAIL: test-n

Re: Provide a module for `clear_cache'

Hello Bruno, Am Mo., 6. Nov. 2023 um 19:33 Uhr schrieb Bruno Haible : [...] I can provide such a thing easily. In fact, I have it already sitting > around on my disk since 2021 :-) > This is great! > > GNU > > lightning currently calls libgcc's `__clear_cache' directly ([1]), but > this > > w

Re: Provide a module for `clear_cache'

Hello Marc, > The idea is to offer the builtin procedure > > __builtin__clear_cache (void *begin, void *end), > > which is provided at least by gcc and clang, in a portable manner. From > the documentation of gcc's version: > > "This function is used to flush the processor’s instruction cache

Provide a module for `clear_cache'

The idea is to offer the builtin procedure __builtin__clear_cache (void *begin, void *end), which is provided at least by gcc and clang, in a portable manner. From the documentation of gcc's version: "This function is used to flush the processor’s instruction cache for the region of memory betw

Re: fenv-*: Port to Minix

I wrote: > which clearly indicates a problem with the feclearexcept() function. But when feclearexcept() is buggy, the configure test checking whether fesetexceptflag is guaranteed non-trapping... is not conclusive: It may fail - because feclearexcept is buggy, - or because fesetexceptfl

Re: Patch: Fix OS X PowerPC support

On 06/11/2023 03:09, Sevan Janiyan wrote: Updated version of the patch attached. Sorry about the noise, I suspect the patch is invalid for Leopard. I will follow up with a new patch which splits the case for 10.5 & older, if that is the case, once I've done more testing. Sevan