[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-08-04 Thread Harry van Haaren (Intel)
Thanks Lukasz, Christian, Robie, Matthias, and the various robots and
launchpad janitors: appreciate your help!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Released
Status in binutils package in Debian:
  Confirmed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-08-04 Thread Launchpad Bug Tracker
This bug was fixed in the package binutils - 2.30-21ubuntu1~18.04.4

---
binutils (2.30-21ubuntu1~18.04.4) bionic; urgency=medium

  * d/p/lp-1883880-x86-don-t-mistakenly-scale-non-8-bit-displacements.patch:
avoid scaling displacements that breaks e.g. some AVX512 code (LP: #1883880)

 -- Christian Ehrhardt   Thu, 18 Jun
2020 13:03:55 +0200

** Changed in: binutils (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Released
Status in binutils package in Debian:
  Confirmed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-08-04 Thread Łukasz Zemczak
It is a manual process which happens after 7+ days of aging in -proposed
- but I have just confirmed the verification and will be proceeding to
release this into -updates. Thank you for your testing!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Released
Status in binutils package in Debian:
  Confirmed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-31 Thread Harry van Haaren (Intel)
Hey Folks,

Does the -proposed changes get automatically integrated to -updates
after a certain time has passed, or does this require somebody to take
action?

It would be great to have this update rolled out to 18.04 before OVS
2.14 is released in a week or two.

Regards, -Harry

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Committed
Status in binutils package in Debian:
  Confirmed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-21 Thread Harry van Haaren (Intel)
Hi All,

I have enabled the bionic-proposed repo as described in link. OVS-master
is used for testing, containing the build-time binutils bug check as
described above.

1) Can confirm that old binutils version (2.30-21ubuntu1~18.04.3) had
issue, and OVS was correctly DISabling AVX512.

2) Can confirm that with -proposed binutils (2.30-21ubuntu1~18.04.4),
OVS build system is correctly ENabling AVX512 support, as linker checks
are passing.

After the configure step, I have tested OVS, running traffic and
enabling the AVX512 optimizations. It is working as expected, with
AVX512 instructions running in the datapath.

I believe you have already added the "verification-done" and bionic
versions Christian, so I'll not change the status... please let me know
if I misunderstood the process.

Thanks Robie & Christian for your support on this issue! -Harry

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Committed
Status in binutils package in Debian:
  Confirmed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-20 Thread Bug Watch Updater
** Changed in: binutils (Debian)
   Status: Unknown => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Committed
Status in binutils package in Debian:
  Confirmed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-16 Thread Christian Ehrhardt 
** Bug watch added: Debian Bug tracker #963702
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963702

** Also affects: binutils (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963702
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Committed
Status in binutils package in Debian:
  Unknown

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-16 Thread Christian Ehrhardt 
Autopkgtest issues resolved, all good now.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-16 Thread Christian Ehrhardt 
with:
2.30-21ubuntu1~18.04.3

root@b:~# echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d 
avx.o | grep vmovaps
   0:   62 f1 7c 48 28 04 05vmovaps 0x1(,%rax,1),%zmm0


with:
2.30-21ubuntu1~18.04.4

root@b:~# echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d 
avx.o | grep vmovaps
   0:   62 f1 7c 48 28 04 05vmovaps 0x40(,%rax,1),%zmm0

Setting verified, but please feel free to
a) keep this in proposed a bit longer
b) @Harry could you test the proposed changes to the OVS build system again?

** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-15 Thread Robie Basak
Hello Christian, or anyone else affected,

Accepted binutils into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/binutils/2.30-21ubuntu1~18.04.4 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
bionic to verification-done-bionic. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-bionic. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: binutils (Ubuntu Bionic)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-14 Thread Christian Ehrhardt 
To have a bileto PPA with security only (thanks Sil2100 for stopping it to 
reconfigure itself) look at:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4151

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-14 Thread Christian Ehrhardt 
On first check by the SRU team I got:
[18:34]  cpaelzer: ok, looking at the binutils SRU, so you talked to 
do_ko about it, right? Was he +1 on the change?

He was in a private IRC, I now asked him to state it here as well so
that it is visible to the SRU team. And he already did so - thanks!

[18:35]  cpaelzer: also, since this is a toolchain package, we
need to first build it in a -security only PPA, as we need it to go to
both -updates and -security

Hmm, I didn't know that is a common pre-check for toolchain packages - thanks 
for the hint.
I have opened a security only all-bionic-arch enabled PPA for this and started 
a build at:
=> https://launchpad.net/~paelzer/+archive/ubuntu/lp-1883880-binutils-sec-only
The first few builds are completed by now.

I hope this helps to remove the remaining blockers to get this into
bionic-proposed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-14 Thread Matthias Klose
yes, this looks sensible as a SRU

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-01 Thread Harry van Haaren (Intel)
Hi Christian,

Thanks for the additional info! Confirm that with the PPA the proposed
checks now pass:

$ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
  8:   0: 62 f1 7c 48 28 04 05vmovaps 0x40(,%rax,1),%zmm0


Also the proposed OVS automake build-system changes will enable avx512 
correctly:
checking binutils avx512 assembler checks passing... yes

I'll wait for the SRU team to accept into proposed. Regards, -Harry

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-07-01 Thread Christian Ehrhardt 
Hi Harry,
the real action/verification will be needed ocne the SRU team has accepted that 
into proposed [1].
If you want to test the PPA the following will enable it on your system:
  $ sudo add-apt-repository ppa:ci-train-ppa-service/4105

The PPA tells you that on its front page [2] as well, I just happen to
link the sub-page with the package details as I more often want to check
build/version details. I beg your pardon that was my fault not realizing
you could make better use the entry page instead.

[1]: https://wiki.ubuntu.com/StableReleaseUpdates
[2]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4105

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-30 Thread Harry van Haaren (Intel)
Hey Folks,

Apologies I'm not familiar with the SRU testing process. I'd like to
help - have an 18.04 setup for testing here. Is there an easy way to add
the test-build PPA and just do an apt update && apt install binutils?

https://launchpad.net/~ci-train-ppa-
service/+archive/ubuntu/4105/+packages

Regards, -Harry

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-23 Thread Christian Ehrhardt 
I got doko to have a quick look (as he is unavailable atm) which seemed ok.
This was mostly to hear from him if this was an overall horrendous idea (it 
isn't) and not to check every line, so this should be ok as-is then.
Further as stated above all other pre-checks against the PPA are good as well.

I uploaded to bionic-unapproved for consideration by the SRU Team.

** Changed in: binutils (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: binutils (Ubuntu Bionic)
 Assignee: Matthias Klose (doko) => Christian Ehrhardt  (paelzer)

** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-22 Thread Christian Ehrhardt 
A few dep8 tests failed in the sniff, but all of them are existing known
overrides in Bionic:

ubuntu-release:9:force-badtest dh-ada-library/6.12
ubuntu-release:18:force-badtest lintian/2.5.81ubuntu1
pitti:2:force-badtest rpmlint/1.9-6
ubuntu-sru:17:force-badtest snapcraft/2.43.1+18.04/amd64 
snapcraft/2.43.1+18.04/i386
ubuntu-sru:20:force-badtest snapcraft/2.43.1+18.04/armhf 
snapcraft/2.43.1+18.04/arm64
ubuntu-release:90:force-badtest linux-hwe/all
ubuntu-release:91:force-badtest linux-hwe-edge/all

So this should be good as-is, but needs Doko to sign-off and sponsor
with the experience of potential side effects of a binutils update.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  New

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-22 Thread Christian Ehrhardt 
Tested in Bionic Container:

no PPA:
root@b:~# echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d 
avx.o | grep vmovaps
   0:   62 f1 7c 48 28 04 05vmovaps 0x1(,%rax,1),%zmm0

with PPA:
root@b:~# echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d 
avx.o | grep vmovaps
   0:   62 f1 7c 48 28 04 05vmovaps 0x40(,%rax,1),%zmm0

Seems to work as intended

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  New

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-19 Thread Christian Ehrhardt 
Added an SRU Teamplate entry in the description, thanks Bruce for the
test.

The changes build fine, all self tests on build are good [1].
The dep8 sniff tests have just started at [2] and will later be available there.
The changes are rather small as seen on [3]

But while all that shall help by being good preparation I have no experience on 
binutils.
Therefore I'd now assign to doko so that he can ack or comment why this 
won't be able to happen.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4105/+packages
[2]: https://bileto.ubuntu.com/#/ticket/4105
[3]: 
https://code.launchpad.net/~paelzer/ubuntu/+source/binutils/+git/binutils/+merge/386073

** Description changed:

+ [Impact]
+ 
+  * the assembler scales non 8 bit cases which was identified
+to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
+time error. Instead the instructions might silently be corrupted until 
+running. Things might even work on some but fail on other systems if 
+e.g. the AVX code paths only run on newer chips.
+ 
+   * The fix is upstream for a while and not re-changed again. Furthermore 
+ it is in several Ubuntu releases without bugs due to that, which should 
+ make the backport rather safe.
+ 
+ [Test Case]
+ 
+  * Simple example to trigger the bug:
+ 
+ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
+ avx.o | grep vmovaps
+ 
+ The expected output is that the objdump output matches the vmovaps
+ instruction input. When using binutils with the bug, the initial 0x40
+ will be incorrect.
+ 
+ Working:
+ $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
+0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
+ Failing:
+ $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
+0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0
+ 
+ [Regression Potential]
+ 
+  * Well, this is a double edged sword. On one hand this is fortunately a 
+small change and only affects something formerly clearly broken. So it 
+should be good and only change cases formerly being bad.
+But OTOH binutils areused in so many cases that I feel unable to say
+"nothing will happen". The change goes to the gnu assembler, so that is 
+the place to look out for regressions.
+ 
+ [Other Info]
+  
+  * needs a sponsor experienced with binutils to check potential pitfalls
+ 
+ 
+ 
+ ---
+ 
+ 
  Hi,
  DPDK has run into some issues in the past
-  https://bugs.dpdk.org/show_bug.cgi?id=97
-  https://bugs.dpdk.org/show_bug.cgi?id=249
+  https://bugs.dpdk.org/show_bug.cgi?id=97
+  https://bugs.dpdk.org/show_bug.cgi?id=249
  
  Eventually the issues got resolved in binutils via
-  https://sourceware.org/bugzilla/show_bug.cgi?id=23465
+  https://sourceware.org/bugzilla/show_bug.cgi?id=23465
  
  After binutils is fixed people rebuilding DPDK themselve can use
-  http://patches.dpdk.org/patch/71679/
+  http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.
  
  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

** Changed in: binutils (Ubuntu Bionic)
 Assignee: (unassigned) => Matthias Klose (doko)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  New

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d 

[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-19 Thread Launchpad Bug Tracker
** Merge proposal linked:
   
https://code.launchpad.net/~paelzer/ubuntu/+source/binutils/+git/binutils/+merge/386073

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  New

Bug description:
  [Impact]

   * the assembler scales non 8 bit cases which was identified
 to break e.g. some AVX512 code. It is nasty as it isn't a compile/link/ 
 time error. Instead the instructions might silently be corrupted until 
 running. Things might even work on some but fail on other systems if 
 e.g. the AVX code paths only run on newer chips.

* The fix is upstream for a while and not re-changed again. Furthermore 
  it is in several Ubuntu releases without bugs due to that, which should 
  make the backport rather safe.

  [Test Case]

   * Simple example to trigger the bug:

  echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
  avx.o | grep vmovaps

  The expected output is that the objdump output matches the vmovaps
  instruction input. When using binutils with the bug, the initial 0x40
  will be incorrect.

  Working:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x40(,%rax,1),%zmm0
  Failing:
  $ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
 0: 62 f1 7c 48 28 04 05 vmovaps 0x1(,%rax,1),%zmm0

  [Regression Potential]

   * Well, this is a double edged sword. On one hand this is fortunately a 
 small change and only affects something formerly clearly broken. So it 
 should be good and only change cases formerly being bad.
 But OTOH binutils areused in so many cases that I feel unable to say
 "nothing will happen". The change goes to the gnu assembler, so that is 
 the place to look out for regressions.

  [Other Info]
   
   * needs a sponsor experienced with binutils to check potential pitfalls


  
  ---

  
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-18 Thread Harry van Haaren (Intel)
Proposed patch on OVS Mailing list to check status at configure time for OVS 
2.14 using the method Bruce mentioned above:
https://patchwork.ozlabs.org/project/openvswitch/patch/20200618165354.87787-7-harry.van.haa...@intel.com/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  New

Bug description:
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-17 Thread Bruce Richardson (Intel)
Command to reproduce the issue:

echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d
avx.o | grep vmovaps

The expected output is that the objdump output matches the vmovaps
instruction input. When using binutils with the bug, the initial 0x40
will be incorrect.

>From an Ubuntu 20.04 system:

$ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
   0:   62 f1 7c 48 28 04 05vmovaps 0x40(,%rax,1),%zmm0

On an Ubuntu 18.04 system:

$ echo "vmovaps 0x40(,%rax,1),%zmm0" | as --64 -o avx.o && objdump -d avx.o | 
grep vmovaps
   0:   62 f1 7c 48 28 04 05vmovaps 0x1(,%rax,1),%zmm0

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  New

Bug description:
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1883880] Re: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

2020-06-17 Thread Harry van Haaren
Hi All,

I contacted Christian to mention/report, just noting that here.
Happy to test if we get an SRU, I'll get email notifications once I post this :)

Regards, -Harry

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to binutils in Ubuntu.
https://bugs.launchpad.net/bugs/1883880

Title:
  fix non-8-bit x86 displacements breaking AVX512 builds on Bionic

Status in binutils package in Ubuntu:
  Fix Released
Status in binutils source package in Bionic:
  New

Bug description:
  Hi,
  DPDK has run into some issues in the past
   https://bugs.dpdk.org/show_bug.cgi?id=97
   https://bugs.dpdk.org/show_bug.cgi?id=249

  Eventually the issues got resolved in binutils via
   https://sourceware.org/bugzilla/show_bug.cgi?id=23465

  After binutils is fixed people rebuilding DPDK themselve can use
   http://patches.dpdk.org/patch/71679/
  to gain more performance while on Bionics bintuils level.

  Note: Bionic is on DPDK 17.11.x which will not get further stable release 
afaik. But quite often people build their own DPDK. In fact this came up as a 
request from Openvswitch upstream/Intel to allow such builds on Bionic.
  I'd ping those people about the bug and ask them to participate in the 
verification if this becomes an SRU.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp