void-packages/srcpkgs/sympow/patches/first-try-without-messing-t...

--- a/Configure	2020-04-16 14:12:56.000000000 -0300
+++ b/Configure	2021-11-24 16:04:43.647041822 -0300
@@ -154,10 +154,10 @@
     try_add_CFLAG $FLAG bypass && break
 done
 
 # Select the most appropriate FPU control scheme
-for FLAG in '-DISOC99_FENV' '-DFPUCONTROLH' '-Dx86'; do
+for FLAG in '' '-DISOC99_FENV' '-DFPUCONTROLH' '-Dx86'; do
     try_add_CFLAG $FLAG && break
 done
 
 # Some flags to try as last resort.  These hurt performance, so only add
 # them if needed.
sympow: do not mess with fpu control word if possible Also: add basic tests to detect fpu miscompilation. The program sets the fpu to 53 bit mode to get consistent results. It turns out that doing this on musl breaks fmt_fp (-> printf) which uses long double to format floats. Note this is an issue even on 64 bit musl, although setting fpu to 53 bits is unnecessary on 64 bits because of the default -mfpmath=sse. The way Configure works: it tries different combinations of flags which exercise different methods to change the fpu control word until one works, meaning doubles are effectively 53 bits. The fix here is to try first NOT touching the fpu control word. On x86_64 using the default -mfpmath=sse this will succeed bypassing all fpucw modification. For i686 using -mfpmath=387 (always if sse2 not available) the code will fall back to changing the fpu control word as before. Since this is not a problem for glibc, everything still works. I expect i686-musl to still be broken, but we don't support that arch. A simple way to test the bug on musl is to run $ sympow -curve '[0,0,0,0,1]' -analrank ... Analytic Rank is 0 : L-value 7.01091e-01 When the fpucw is changed, on musl 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. Again: what is broken is not computing but printing, as fmt_fp in musl uses long double, which means messing with fpu control word breaks it. 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 on the 3 supported archs. 2021-11-22 23:24:50 +01:00			`--- a/Configure 2020-04-16 14:12:56.000000000 -0300`
			`+++ b/Configure 2021-11-24 16:04:43.647041822 -0300`
			`@@ -154,10 +154,10 @@`
			`try_add_CFLAG $FLAG bypass && break`
			`done`

			`# Select the most appropriate FPU control scheme`
			`-for FLAG in '-DISOC99_FENV' '-DFPUCONTROLH' '-Dx86'; do`
			`+for FLAG in '' '-DISOC99_FENV' '-DFPUCONTROLH' '-Dx86'; do`
			`try_add_CFLAG $FLAG && break`
			`done`

			`# Some flags to try as last resort. These hurt performance, so only add`
			`# them if needed.`