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&sponsor 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1883880 Title: fix non-8-bit x86 displacements breaking AVX512 builds on Bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1883880/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
