devel April 2022

devel@uclibc-ng.org

3 participants
3 discussions

Bug in memset on ARM
by tombannink＠gmail.com 13 Apr '22

13 Apr '22

Hi, The ARM implementation of memset has a bug when the fill-value is negative or outside the [0, 255] range. To reproduce: int main() { char array[256]; memset(array, -5, 256); for (int i = 0; i < 256; ++i) { printf("%d, ", (int)array[i]); } return 0; } This is supposed to fill the array with int8 values -5, -5, -5, ... . On ARM, this does not work because the implementation assumes the high bytes of the fill-value argument are already zero. However in this test case they are filled with 1-bits. The other implementations that I checked (aarch64 and x86_64) do not have this problem: they first convert the fill-value to an unsigned byte following the specification of memset. With GCC one can use `memset(ptr, (-5 & 0xFF), size)` as a workaround, but for clang users that does not work: clang optimizes the `& 0xFF` away because it assumes that memset will do it. How to fix/patch: In this file: https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libc/string/arm/mems… Before line 35 (lsl) insert this: uxtb r1, r1 Before line 71 (orr) insert this: uxtb a2, a2 Best regards, Tom

3 11

Re: Bug in math library of uClibc-ng
by Waldemar Brodkorb 12 Apr '22

12 Apr '22

Hi Tom, Tom Bannink wrote, > Hi uClibc-ng developers, > > I've stumbled across a bug in the implementation of `lrint` in uClibc-ng. I'm > not sure where to report this so I'm sending this email. Please let me know if > I can submit an issue on a bugtracker somewhere. I tried to post an issue on > the gitlab page (https://gogs.waldemar-brodkorb.de/oss/uclibc-ng/issues) but it > seems I cannot make an account there. > > The bug is simple to reproduce: `lrint(0.5)` and `lrint(-0.5)` should return 0 > (or +-1 depending on the rounding mode) but instead they return 2 and -2 > respectively. > > The faulty code is the block at lines 55-64 of this file: https:// > cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libm/s_lrint.c > Note that the `lround` function works fine and has very similar code: https:// > cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/tree/libm/s_lround.c > > Let me know if you need more information. Can you provide a simple test case for the issue? best regards Waldemar

2 3

[PATCH] libm: fix bug in s_lrint.c
by Waldemar Brodkorb 12 Apr '22

12 Apr '22

Following test case returns 2, which should be 0. int main() { long x = lrint(0.5); printf("%ld", x); return 0; } Fix from glibc commit 6624dbc07b5a9fb316ed188ef01f65b8eea8b47c Signed-off-by: Waldemar Brodkorb <wbx(a)openadk.org> --- libm/s_lrint.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/libm/s_lrint.c b/libm/s_lrint.c index 09800d8de..2a8db9fbe 100644 --- a/libm/s_lrint.c +++ b/libm/s_lrint.c @@ -49,19 +49,13 @@ lrint (double x) if (_j0 < 20) { - if (_j0 < -1) - return 0; - else - { - w = two52[sx] + x; - t = w - two52[sx]; - EXTRACT_WORDS (i0, i1, t); - _j0 = ((i0 >> 20) & 0x7ff) - 0x3ff; - i0 &= 0xfffff; - i0 |= 0x100000; - - result = i0 >> (20 - _j0); - } + w = two52[sx] + x; + t = w - two52[sx]; + EXTRACT_WORDS (i0, i1, t); + _j0 = ((i0 >> 20) & 0x7ff) - 0x3ff; + i0 &= 0xfffff; + i0 |= 0x100000; + result = (_j0 < 0 ? 0 : i0 >> (20 - _j0)); } else if (_j0 < (int32_t) (8 * sizeof (long int)) - 1) { -- 2.30.2

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

devel April 2022