[PATCH v2] math: Mark many {u}fromfp/{u}fromfpx tests as XFAIL for, ldbl-128ibm

[Sachin Monga]

Joseph,

Thank you for the review and for pointing out the issue with editing the 
generated .inc files — you're absolutely right.

I shouldn't have proposed changes directly to the generated files 
(libm-test-fromfp.inc, etc.), as those are produced by 
gen-fromfp-tests.py and manual edits would be lost on regeneration. My 
apologies for that oversight.

I fully agree that fixing the underlying signed-zero bugs is the proper 
and cleaner long-term solution, rather than using XFAILs or trying to 
adjust the test generator.

However, With glibc 2.43 targeted for release, would it be acceptable to 
ship in the current state — without any XFAIL markings for these 
fromfp/fromfpx failures on powerpc64? The test failures are noisy but 
don't reflect any actual regression in the fromfp/fromfpx 
implementations themselves, and we can address the root cause properly 
after the release by fixing the rounding functions. If this cannot be 
shipped in current state then I'll share the updated patch in this case 
marking XFAILs in proper file.

Thanks again for the guidance — looking forward to community thoughts!

Regards: Sachin


On 17/01/26 2:26 am, Joseph Myers wrote:
> On Fri, 16 Jan 2026, Sachin Monga wrote:
>
>>   math/libm-test-fromfp.inc   | 96 ++++++++++++++++++-------------------
>>   math/libm-test-fromfpx.inc  | 96 ++++++++++++++++++-------------------
>>   math/libm-test-ufromfp.inc  | 96 ++++++++++++++++++-------------------
>>   math/libm-test-ufromfpx.inc | 96 ++++++++++++++++++-------------------
> The parts of the files you're editing are generated by
> gen-fromfp-tests.py; it's a bad idea to edit generated text like that as
> the changes would be lost on any subsequent regeneration after
> modifications to gen-fromfp-tests.py or gen-fromfp-tests-inputs.
>
> Fixing the underlying bugs would be better and probably easier than
> teaching gen-fromfp-tests.py to work out what inputs would be affected by
> those bugs.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260119/a91e4b1b/attachment-0001.htm>