Re: Backporting gcc_qsort
On Fri, Sep 28, 2018 at 7:08 PM Cory Fields wrote: > > gcc_qsort as introduced by Alexander Monakov [0] in trunk for 9.x is a > great change that defines the order of otherwise-unbalanced internal > sorts, some of which would otherwise cause bootstrapping failures. > > I would like to request that these it as well as subsequent fixups > (all listed specifically below) be backported to the 8.x branch. They > apply cleanly to 8.x, and I can confirm that they fix qsort-related > bootstrap failures at least in my case of crossing x86_64-gnu to > x86_64-musl. > > Would there be any downside to backporting? It is not something we generally backport. > The changes that I locally backported and tested successfully were: > r260216: Introduce gcc_qsort > r260222: gcc_qsort: avoid oversized memcpy temporaries > r262092: gcc_qsort: avoid overlapping memcpy (PR 86311) > r264065: qsort_chk: call from gcc_qsort instead of wrapping it > > [0]: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00479.html > > Regards, > Cory Fields
Bulletin from the salt mines
This is a note to the GCC list that I have not given up on the repository translation. Having concluded that doing forensics with 9-hour test turnaround times is insupportable and that I had reached the limit of what off-the-shelf hardware and my existing tools could do, I am engaged in translating reposurgeon to the Go language. I expect this to speed up my test cycles by at least an order of magnitude. Actually, published Python-vs.-Go benchmarks for programs with similar resource-usage distributions suggest that a speedup factor of *40* is a realistic expectation. That would pull my test runs down to about 15 minutes each. I also expect a drastic reduction in working set, eliminating the memory pressure I was having on the later runs. Python's per-object overhead is pretty large (for example, every Python string has a fixed base cost of 40 bytes). Go's is perhaps a bit larger than C's due to its type-reflection support, but not overly so. Even though the semantic gap between Python and Go is relatively small, translating 14KLOC of algorithmically dense Python to *anything* else is necessarily a huge undertaking. I did not wish to announce the effort until I was well into it and reasonably confident of success. This morning the translation reached its 30% mark. That gives me reasonable confidence. There is still difficulty ahead, however. A copy-on-write store that was central to the interpretation of Subversion dumps turned out not to be practically implementable in a language with static types and no iterators. I'm going to have to rework significant parts of the Subversion dump interpreter to get around that, and if you guessed that that is the most opaque and dangerous part of the codebase (and the locus of the translation bugs reported here) you got that right. I shall persevere. The necessity was unfortunate, but one effect of the translation is that I'm writing unit tests for each piece as I go. There is good reason to hope that thus will make fault isolation easier than it was in the Python version. -- http://www.catb.org/~esr/";>Eric S. Raymond Gun Control: The theory that a woman found dead in an alley, raped and strangled with her panty hose, is somehow morally superior to a woman explaining to police how her attacker got that fatal bullet wound. -- L. Neil Smith
Re: Backporting gcc_qsort
On 10/1/18 2:20 AM, Richard Biener wrote: > On Fri, Sep 28, 2018 at 7:08 PM Cory Fields wrote: >> >> gcc_qsort as introduced by Alexander Monakov [0] in trunk for 9.x is a >> great change that defines the order of otherwise-unbalanced internal >> sorts, some of which would otherwise cause bootstrapping failures. >> >> I would like to request that these it as well as subsequent fixups >> (all listed specifically below) be backported to the 8.x branch. They >> apply cleanly to 8.x, and I can confirm that they fix qsort-related >> bootstrap failures at least in my case of crossing x86_64-gnu to >> x86_64-musl. >> >> Would there be any downside to backporting? > > It is not something we generally backport. To add a bit more context for Cory. Generally backports are limited to fixing regressions and serious code generation bugs. While we do make some exceptions, those are good general guidelines. I don't think the qsort changes warrant an exception. jeff
Re: Backporting gcc_qsort
On Mon, 1 Oct 2018, Jeff Law wrote: > To add a bit more context for Cory. > > Generally backports are limited to fixing regressions and serious code > generation bugs. While we do make some exceptions, those are good > general guidelines. > > I don't think the qsort changes warrant an exception. Personally I think in this case there isn't a strong reason to backport, the patch is fairly isolated, so individuals or companies that need it should have no problem backporting it on their own. Previously, Franz Sirl reported back in June they've used the patch to achieve matching output on their Linux-hosted vs Cygwin-hosted cross-compilers based on GCC 8: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00751.html Alexander
Re: Backporting gcc_qsort
Understood. Thank you for the explanations. I'll just plan to apply the patches locally as well. Regards, Cory On Mon, Oct 1, 2018 at 11:18 AM Alexander Monakov wrote: > > On Mon, 1 Oct 2018, Jeff Law wrote: > > To add a bit more context for Cory. > > > > Generally backports are limited to fixing regressions and serious code > > generation bugs. While we do make some exceptions, those are good > > general guidelines. > > > > I don't think the qsort changes warrant an exception. > > Personally I think in this case there isn't a strong reason to backport, the > patch is fairly isolated, so individuals or companies that need it should have > no problem backporting it on their own. Previously, Franz Sirl reported back > in June they've used the patch to achieve matching output on their > Linux-hosted > vs Cygwin-hosted cross-compilers based on GCC 8: > https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00751.html > > Alexander
armeb bug: -mtune=cortex-a15 broken with -mbe8
Hello, Compiling with "-march=armv7-a -mtune=cortex-a15 -mbe8" produces code that appears to change the order of words. For example, the word-wise optimized strcpy in musl changes "/dev/fd/" into "/fd//dev". Removing "mtune=cortex-a15" works around the problem. Presumably this is due to some instructions used in cortex-a15 mode that assume little endian data, when -mbe8 requires otherwise. Thanks, Jason $ armeb-pc-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=armeb-pc-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armeb-pc-linux-gnueabi/8.2.0/lto-wrapper Target: armeb-pc-linux-gnueabi Configured with: /var/tmp/portage/cross-armeb-pc-linux-gnueabi/gcc-8.2.0-r3/work/gcc-8.2.0/configure --host=x86_64-p c-linux-gnu --target=armeb-pc-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux- gnu/armeb-pc-linux-gnueabi/gcc-bin/8.2.0 --includedir=/usr/lib/gcc/armeb-pc-linux-gnueabi/8.2.0/include --datadir=/u sr/share/gcc-data/armeb-pc-linux-gnueabi/8.2.0 --mandir=/usr/share/gcc-data/armeb-pc-linux-gnueabi/8.2.0/man --infod ir=/usr/share/gcc-data/armeb-pc-linux-gnueabi/8.2.0/info --with-gxx-include-dir=/usr/lib/gcc/armeb-pc-linux-gnueabi/ 8.2.0/include/g++-v8 --with-python-dir=/share/gcc-data/armeb-pc-linux-gnueabi/8.2.0/python --enable-languages=c,c++, fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-get text --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.2.0-r3 p1.3' --dis able-esp --enable-libstdcxx-time --enable-poison-system-directories --with-sysroot=/usr/armeb-pc-linux-gnueabi --dis able-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --with-float=soft --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --ena ble-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --enable-default-pie --enable-def ault-ssp Thread model: posix gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.3)
