Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1050413 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#983807: spring builds with -march=native on amd64 Adrian Bunk <bunk@debian.org> - 2021-03-01 23:00 +0100
    Bug#983807: spring builds with -march=native on amd64 Markus Koschany <apo@debian.org> - 2021-03-01 23:50 +0100
      Bug#983807: spring builds with -march=native on amd64 Adrian Bunk <bunk@debian.org> - 2021-03-02 00:10 +0100
    Bug#983807: spring builds with -march=native on amd64 Markus Koschany <apo@debian.org> - 2021-03-02 00:40 +0100
      Bug#983807: spring builds with -march=native on amd64 Sebastian Ramacher <sramacher@debian.org> - 2021-03-02 09:00 +0100
    Bug#983807: spring builds with -march=native on amd64 Adrian Bunk <bunk@debian.org> - 2021-03-02 00:40 +0100

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

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.

Fix:

--- debian/rules.old	2021-03-01 21:06:07.743433910 +0000
+++ debian/rules	2021-03-01 21:31:31.399556520 +0000
@@ -13,7 +13,7 @@
 ifeq ($(DEB_HOST_ARCH_CPU),i386)
 	MARCH_FLAG :="i686"
 else
-	MARCH_FLAG :="native"
+	MARCH_FLAG :="x86-64"
 endif
 
 %:

[toc] | [next] | [standalone]

#1050420

[Multipart message — attachments visible in raw view] — view raw

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? 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? What
concrete drawback do you experience when you use the Spring engine on amd64?

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#1050422

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.

Users can expect that all software we ship works on the baseline
of an architecture.

> 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.

> Regards,
> 
> Markus

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#1050427

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 normal

Am Dienstag, den 02.03.2021, 01:32 +0200 schrieb Adrian Bunk:
[...]
> > 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.

I do not think this is a release critical bug. I disagree with you assumptions.
The package works fine.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#1050460

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 serious

On 2021-03-02 00:37:37 +0100, Markus Koschany wrote:
> Control: severity -1 normal
> 
> Am Dienstag, den 02.03.2021, 01:32 +0200 schrieb Adrian Bunk:
> [...]
> > > 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.
> 
> I do not think this is a release critical bug. I disagree with you assumptions.
> The package works fine.

Violating the baseline of an architecture is an RC bug. The i386 build
is not usable on non-SSE CPUs. The i386 architecture still supports
those, though.

It's fine to build some parts with -msse if there is runtime detection
and a fallback.

Cheers
-- 
Sebastian Ramacher

[toc] | [prev] | [next] | [standalone]

#1050428

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web