On Sat, Feb 20, 2021 at 07:24:52PM +0000, Olly Betts wrote:
> On Fri, Feb 19, 2021 at 11:36:46AM +0200, Adrian Bunk wrote:
> > With the old debian/rules the test was only run with
> > the SSE build.
> >
> > If exact results are required and the x87 excess precision is unwanted,
> > test with the non-SSE build can be fixed with:
> >
> > --- debian/rules.old 2021-02-18 15:12:59.097207579 +0000
> > +++ debian/rules 2021-02-18 15:13:51.537168694 +0000
> > @@ -51,6 +51,10 @@
> >
> > export DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
> >
> > +ifneq (,$(filter $(DEB_HOST_ARCH), i386 m68k))
> > + export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store
> > +endif
> > +
> > # For i386 and *-i386.
> > ifeq ($(patsubst %-i386,i386,$(DEB_HOST_ARCH)), i386)
> > XAPIAN_BUILD_SSE := 1
>
> Thanks for the report, and for tracking this down to excess precision.
>
> The upstream code is meant to address excess precision in the small
> number of places where it matters but I guess there's a newer instance
> that hasn't been caught before, or a newer testcase uncovers an existing
> problem (or perhaps newer GCC optimises differently and that's uncovered
> this.)
>
> The SSE2 build will get used by more i386 systems, so the overhead
> from -ffloat-store won't affect many there at least, but it is a bit of
> heavy hammer. I'll take a look and see if I can fix this in a more
> targetted way. If not applying this for bullseye seems reasonable.
> Or we could change the tests back to run just for the SSE2 build for
> now - in real world use exact results are rarely a requirement, but
> performance often is.
Investigating on i386 I found that all the failures apart from ordecay1
appear to actually be from the effects of excess precision on testcase
code itself (and looking at the m68k log, ordecay1 actually passes
there.)
As you note, on i386 the test was only run with the SSE build before
the recent debian/rules modernisation, but that doesn't explain why
m68k now fails. Looking at older m68k logs, it seems the testsuite
wasn't being run, though I'm not seeing why not.
I think given where we are in the bullseye freeze the least invasive
change here makes sense, which is to not run the tests for the i386
non-SSE build (they are run for the SSE build, which is the build
which gets used on SSE2-capable machines, which is most of them)
or on m68k (which isn't ideal, but it isn't a release architecture
currently.) This essentially restores the testing situation to what
it was prior to my modernisation of debian/rules in the previous
upload.
Longer term, sorting out ordecay1 and the testsuite issues (perhaps
building the testsuite with -ffloat-store on affected platforms.)
Cheers,
Olly
