Bug#303478: forcely is not a word

2005-04-06 Thread Noah Meyerhans
Package: libc6 Version: 2.3.2.ds1-20 Severity: minor In the libc6 postinst, the following can be found on line 89: echo Non-interactive mode, upgrade glibc forcely forcely is not a word in the English language (at least, not according to any dictionary I've found). Maybe you mean forcibly or

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Noah Meyerhans
On Sat, Apr 11, 2020 at 10:23:54PM +0200, Florian Weimer wrote: > Or put differently: If upstream doesn't want to default to > -moutline-atomics, why should Debian? Well, ultimately we own our build configurations and the optimizations we enable therein. If we don't want to enable

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Noah Meyerhans
On Sat, Apr 11, 2020 at 08:44:29AM +0200, Florian Weimer wrote: > > Gcc provides two ways to enable support for these instructions at build > > time. The simplest, and least disruptive, is to enable -moutline-atomics > > globally in the arm64 glibc build. > > Shouldn't GCC do this by default, at

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-11 Thread Noah Meyerhans
On Sat, Apr 11, 2020 at 09:14:11PM +0200, Florian Weimer wrote: > > At least if I'm reading the code right (which I may very well not be > > doing, being generally unfamiliar with gcc internals), -mtune=generic > > enables the equivalent of ARMv8 support: > > > >

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-10 Thread Noah Meyerhans
Package: src:glibc Version: 2.30-4 Severity: wishlist X-Debbugs-CC: debian-...@lists.debian.org The ARMv8.1 spec, as implemented by the ARM Neoverse N1 processor, introduces a set of instructions [1] that result in significant performance improvements for multithreaded applications. Sample code

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-21 Thread Noah Meyerhans
On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: > > Significant performance impact has also been observed in less contrived > > cases (MariaDB and Postgres), but I don't have a repro to share. > > But indeed what counts is number on real workloads. It would be nice to > get

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-05-04 Thread Noah Meyerhans
On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote: > The hardware capabilities system works fine upstream, but doesn't work > for us because: > 1) we want to be able to upgrade major upstream version online (as > opposed to fedora for example) > 2) we ship the optimized libraries in a

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-04-22 Thread Noah Meyerhans
On Wed, Apr 22, 2020 at 05:48:27PM +0100, Steve McIntyre wrote: > I think the -moutline-atomics is probably good to enable by default > once we've got it (gcc 10). that's the suggestion I've heard from gcc > folks in Arm. JFTR, it's been backported to gcc 9 and is available in Debian's gcc-9 as

Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1

2020-05-07 Thread Noah Meyerhans
On Wed, May 06, 2020 at 04:15:09PM +0200, Aurelien Jarno wrote: > > >One solution for this would be to ship the optimized library in the same > > >package as the default library. Now this is not acceptable for embedded > > >systems as they might not need that library and can't remove it. This is >