Hi Bastian, Il sab 23 ott 2021, 11:58 Bastian Germann <b...@debian.org> ha scritto:
> Am 23.10.21 um 10:43 schrieb Giulio Paci: > > Since the NMU has already solved the FTBFS, I think I can try to upgrade > > the tool as well. Unfortunately upstream did not add neither a tag nor a > > release to github. I have just asked if it is possible to add them > > (before moving to github upstream used to release tarballs with any new > > release). > > As the last commit is the one changing the version and is from 2018, it > is reasonable to assume that that commit is the release. There is no > activity since then and I do not expect upstream to react to your > request. So please package 2.4.11 regardless of tags. > I have discussed with upstream and they agreed to merge some of the currently open pull requests, as well as tag new versions, so I will package latest version (currently 2.4.12) as soon as I find time. > > I have invited you to https://salsa.debian.org/debian/sctk which also runs > the Salsa CI pipelines to demonstrate the i386 issue. Please use that repo > going forward. I will do. Thank you for setting it up. Build tests on i386 fail with: test17: Vietnamese case conversion Executions complete: Comparing output Removing DIFF tests Removing SLM tests !!!!! TESTS HAVE FAILED !!!!! I checked the issue and found out that the failing tests are test13 and test13b in sclite. The failing test case relies on the assumptions that, when a and b have the same double value: 1) "a < b" is false; 2) "a - b" is 0.0. For some reason the two above assumptions are sometime disattended on i386, and thus the "overlap" function in src/sclite/ctm2ctm.c is not always providing the expected results. The overlap behavior is unstable and varies according to specific flags being used to compile the executable (e.g., enabling debug is often enough to not trigger the failure, but enabling -O3 and -mtune=native generally is enough to trigger the failure again) or the context surrounding the operations (e.g., accessing the memory address of the operands). I guess the main reason for this weird behavior is described in (option -mfpmath): https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options and in (option -ffloat-store): https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options . Using -ffloat-store option indeed seems to fix the issue. However I am wondering: 1) is this the proper solution? 2) is it correct that the compiler does not guarantee the above assumptions? Do you have any suggestion? Best regards, Giulio
