[PR PATCH] sympow: on musl, do not mess with fpu control word

[tornaria <tornaria@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

There is a new pull request by tornaria against master on the void-packages repository

https://github.com/tornaria/void-packages sympow
https://github.com/void-linux/void-packages/pull/34209

sympow: on musl, do not mess with fpu control word
It turns out doing that results in broken precision, and not doing it
fixes it.

A simple way to test it is to run

    $ sympow -curve '[0,0,0,0,1]' -analrank
    ...
    Analytic Rank is 0 : L-value 7.01091e-01

When broken this prints "7.01092e-01" instead.

The actual value computed to 128 bits with pari is:

    $ echo 'elllseries(ellinit([0,0,0,0,1]),1)' | gp -q
    0.70109105266272713058750953952514706773

so the glibc output is the correct one.

It seems to me that what is broken is not computing but printing, but
this is important since sagemath parses sympow output.

This affects sagemath doctests as in

    $ sage -t src/sage/lfunctions/sympow.py
    ...
    (3 failures)

After this commit, the doctest in question passes.

<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **YES**

The corresponding doctest in sagemath passes on musl with this change; it was failing before.

A patch file from https://github.com/void-linux/void-packages/pull/34209.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-sympow-34209.patch --]
[-- Type: text/x-diff, Size: 1766 bytes --]

From ac4607e56eca77119b40f2d71275bbc812234f43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gonzalo=20Tornar=C3=ADa?= <tornaria@cmat.edu.uy>
Date: Mon, 22 Nov 2021 19:24:50 -0300
Subject: [PATCH] sympow: on musl, do not mess with fpu control word

It turns out doing that results in broken precision, and not doing it
fixes it.

A simple way to test it is to run

    $ sympow -curve '[0,0,0,0,1]' -analrank
    ...
    Analytic Rank is 0 : L-value 7.01091e-01

When broken this prints "7.01092e-01" instead.

The actual value computed to 128 bits with pari is:

    $ echo 'elllseries(ellinit([0,0,0,0,1]),1)' | gp -q
    0.70109105266272713058750953952514706773

so the glibc output is the correct one.

It seems to me that what is broken is not computing but printing, but
this is important since sagemath parses sympow output.

This affects sagemath doctests as in

    $ sage -t src/sage/lfunctions/sympow.py
    ...
    (3 failures)

After this commit, the doctest in question passes.
---
 srcpkgs/sympow/template | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/srcpkgs/sympow/template b/srcpkgs/sympow/template
index d484cf847f57..9a8532ad8a70 100644
--- a/srcpkgs/sympow/template
+++ b/srcpkgs/sympow/template
@@ -1,7 +1,7 @@
 # Template file for 'sympow'
 pkgname=sympow
 version=2.023.6
-revision=2
+revision=3
 wrksrc=${pkgname}-v${version}
 build_style=configure
 make_build_target=all
@@ -16,6 +16,11 @@ checksum=d153530dfdd46da05c954121640e50771064536fedc22c7fef24fb11083172ef
 nocross=yes # runs binaries built for target
 
 do_configure() {
+	case "$XBPS_TARGET_MACHINE" in
+		# changing the fpu control word breaks under musl 64 bit (?)
+		*-musl) sed -i -e 's|fpu_53bits();||' main.c ;;
+	esac
+
 	PREFIX=/usr ./Configure
 }