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

[Adhemerval Zanella Netto]

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.