Bug#983807: spring builds with -march=native on amd64

[Adrian Bunk]

Control: severity -1 serious

On Tue, Mar 02, 2021 at 12:15:38AM +0100, Markus Koschany wrote:
> Control: severity -1 normal
> 
> Am Dienstag, den 02.03.2021, 01:02 +0200 schrieb Adrian Bunk:
> > On Mon, Mar 01, 2021 at 11:39:00PM +0100, Markus Koschany wrote:
> > > Am Montag, den 01.03.2021, 23:53 +0200 schrieb Adrian Bunk:
> > > > Source: spring
> > > > Version: 105.0.1+dfsg-1
> > > > Severity: serious
> > > > Tags: patch
> > > > 
> > > > spring builds with -march=native on amd64, which makes spring
> > > > only work on machines compatible with whatever buildd built it.
> > > 
> > > What Policy violation justifies severity serious for this bug?
> > 
> > The release team agrees that baseline violations are severity serious.
> 
> What do you mean by baseline "violations"?

Unconditional usage of features outside the baseline are baseline violations.

Using AVX on amd64 would be an example for a baseline violation,
unless this is optional code with runtime autodetection.

> > Users can expect that all software we ship works on the baseline
> > of an architecture.
> 
> Agreed. However I don't see that this assumption is not true for Spring
> compiled with march=native on our buildd.

What did you think that -march=native would do?

On amd64 -march=native will always enable instructions that are not in
the port baseline.

> > > Spring is only
> > > built on i386/i686 and amd64. What difference does it make if we switch to
> > > the
> > > generic march=x86-64 when march=native appears to be working fine?
> > > ...
> > 
> > It appears to work, and will work for you if your CPU is compatible with 
> > whatever buildd happened to build it.
> > 
> > We used to have older AMD Opterons among the buildds,
> > gcc would emit 3DNow! instructions that no modern CPU has.
> 
> I would really like to understand what the current drawback is for our users.
> If you could provide the build flags with march=native and march=x86-64 and
> then prove that march=x86-64 prevents some serious issues or makes the engine
> better for users, I would happily apply your patch. Otherwise I am reluctant to
> apply it because there is no current evidence that it improves the package. The
> GCC manual talks about "it _might_" have some drawbacks but it also depends on
> the package. Again where is the concrete drawback for Spring?

The drawback is that Spring does does not work for users whose computer 
is not compatible with whatever buildd happened to build your package.

I am adding debian-release to Cc, please discuss with them if you
think this would not be a release critical bug.

cu
Adrian