Hi Nilesh, after some searching and experimentation, I think `-ffloat-store` doesn't always solve this floating point issue. But this seems to solve it: `-msse2 -mfpmath=sse`.
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html I hope that helps, Martin On Mon, Jul 11, 2022 at 7:56 PM Nilesh Patra <nil...@debian.org> wrote: > Hi Martin and Katoh, > > On Mon, Jul 11, 2022 at 06:40:51PM +0900, Frith, Martin wrote: > > Dear Nilesh and Debian Med > > (cc MAFFT author Katohさん) > > > > I have partly tracked down this lamassemble issue. First, I tested > > lamassemble on x86_64: the tests passed as expected. Then, I recompiled > > MAFFT after adding "-m32" to CFLAGS, which compiled it in 32-bit mode. > Now, > > the tests in > > lamassemble/tests/lama-tests.sh > > do not give the expected results, as you found. > > Thanks a lot for digging in!! > > > So it seems that MAFFT sometimes outputs different results in 32-bit > mode, > > versus 64-bit mode. > > > > I speculate that this is due to floating point calculations, which can > > produce different results in 32-bit versus 64-bit mode. I think this is > > because CPUs use "extended precision" in one mode but not the other. This > > is arguably not a "bug". I guess this must be a frequently occurring > issue, > > how does Debian usually resolve it? > > For floating point issues on i386, usually using a `-ffloat-store` flag > during > compilation does the trick. I compiled mafft on i386 chroot using the same > and tried > testing but unfortunately that does not help (it fails with same errors) > > If nothing comes up, I'll disable testing on i386. > > -- > Best, > Nilesh >
