Monday Patch Queue Review update (2025-11-17)

[Collin Funk]

Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:

> On 17/11/25 11:59, Sam James wrote:
>> Carlos O'Donell <carlos@redhat.com> writes:
>> 
>>> Most recent meeting status is always here:
>>> https://sourceware.org/glibc/wiki/PatchworkReviewMeetings#Update
>>>
>>> Meeting: 2025-11-17 @ 0900h EST5EDT
>>>
>>> Video/Audio: https://bbb.linuxfoundation.org/room/adm-alk-1uu-7fu
>>>
>>> IRC: #glibc on OFTC.
>>>
>>> Review new patches and restart review at the top.
>>> ​
>>>  * State NEW delegate NOBODY at 552 patches.
>>>  * aarch64: fix SVE tanpi(f) (Pierre)
>>>    * Carlos: Needs a bug number. Email sent.
>>>    * Wilco will review.
>>>  * nptl: Check alignment of pthread structs (Wilco)
>>>   * Reviewer Pool: Yury.
>>>  * [v2] Use 64-bit atomic on sem_t with 8-byte alignment [BZ #33632] (HJ)
>>>   * Wilco asking for Adhemerval to review.
>>>   * Adhemerval will review.
>>>  * malloc: retire mechanism for older non used tcached chunks (Cupertino)
>>>   * Reviewer Pool: Florian
>>>  * [v3,1/3] x86/string: Factor out large memmove implemention to seperate file (Noah)
>>>   * Reviewer Pool: DJ
>>>  * Add support for threaded tests, then use with malloc (Arjun)
>>>   * Reviewer Pool: Florian
>>>  * Improve generic fma/fmaf implementation (Adhemerval)
>>>   * Review by Wilco.
>>>  * [v2] pthread: add PTHREAD_NULL (Alyssa)
>>>   * Reviewer Pool: Carlos
>>>  * Stopping at 124101.
>>>  * Discussed accepting Yury's patch for build-many-glibcs.
>>>   * Most of the patches were accepted.
>>>   * Some changes requested.
>>>   * If Yury can't work on this right now then we can review again.
>>>   * Carlos: If Yury can send out a simpler v2 then we can approve that.
>>>  * [v6] linux: Add openat2 (BZ 31664) (Adhemerval)
>>>   * Reviewer Pool: Carlos
>>>  * Add Experimental clang build support (Adhemerval)
>>>   * Still looking for reviewers to approve the more complex parts.
>> 
>> What I really would like is reviewers for the math stuff as I'm not
>> really familiar with our infra for that. The rest I can continue to look
>> at (but help is always welcome ofc).
>
> Thanks for the help so far Sam, I have noted that the more complex stuff
> is really the longlong.h replacement.  The bright side is not it uses the
> already in place code from either generic uint64_t support (for 32 bit
> architectures) or math_uint128.h (for 64 bit architectures).
>
> And the math_uint128.h is already used by tanf and uses compiler support
> for 128 bit integer where possible. 

Likewise, I am not very familiar with the math stuff. Otherwise I would
have finished up reviewing that series.

Collin