similar to: [patch] statfs64 sparc_v9 fix

From: Sjoerd Simons <sjoerd@spring.luon.net> It seems that klibc uses __sparc64__ to determine if it's compiled in 64 bit mode on sparc, unfortunatly gcc doesn't define __sparc64__ :) It does define __arch64__ though. Signed-off-by: maximilian attems <maks@sternwelten.at> --- klibc-1.2.2.orig/include/sys/vfs.h 2006-02-15 18:32:10.000000000 +0100 +++

From: Steve Langasek <vorlon@debian.org> Fix the definition of struct statfs64, required for run-init to work on alpha. verified to have no regressions on amd64. Signed-off-by: maximilian attems <janitor@sternwelten.at> Signed-off-by: Frederik Sch?ler <fschueler-guest@costa.debian.org> --- klibc-1.1.1.orig/include/sys/vfs.h +++ klibc-1.1.1/include/sys/vfs.h @@ -32,17 +32,17

On Thu, 2014-09-25 at 18:41 +0200, Thierry Reding wrote: > On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote: > > On 09/25/2014 07:27 AM, Sjoerd Simons wrote: > > >Playing a bit with todays linux-next on my jetson, it seems this patch is > > >still required for enabling the GPU. Is there anything blocking it (firmware > > >not available yet in

It's checked in, it seems to work, it didn't bloat the system significantly, but it makes life a lot easier... I just released klibc-0.124 with the 64-bit off_t and statfs64 changes. The API shouldn't have changed, but the ABI is now 64 bits in (hopefully) all the right places. It's probably buggy... beat me up or (better) send a patch... -hpa

On Thu, 01 June 2006, H. Peter Anvin wrote: > Brian F. G. Bidulock wrote: > > On Thu, 01 Jun 2006, Bob Picco wrote: > >> > >> -#if !defined(__x86_64__) && !defined(__ia64__) && !defined(__sparc_v9__) > >> +#if !defined(__x86_64__) && !defined(__ia64__) && !defined(__sparc_v9__) && \ > >> +

Hello all, Recently I have started writing some small package apps. The main app I''m working on at the moment is Camping/Photos[1]. Here I use a controller to serve static files (Theme[3]) that I have copied from [2]. There seems a problem however, when using this via lighttpd. All files that get served (via photos-dispatch.rb) get an extra ''\r\n'' in front. This

If you export two subvolumes of a btrfs filesystem, they will both be given the same uuid so lookups will be confused. blkid cannot differentiate the two, so we must use the fsid from statfs64 to identify the filesystem. We cannot tell if blkid or statfs is best without knowing internal details of the filesystem in question, so we need to encode specific knowledge of btrfs in mountd. This is

Hello all, I have an app mounted under /test via lighttpd fastcgi as indicated on [1]. Here I use R(Foo, bar) in views to link to controller foo, this correctly creates a /test/foo/bar link. However, when I use R() in some controller, for example: headers[''Refresh''] = "60; url=#{R(Foo, bar)}" The generated link is /foo/bar, which obviously links to something

On Thu, Sep 25, 2014 at 09:48:01AM -0600, Stephen Warren wrote: > On 09/25/2014 07:27 AM, Sjoerd Simons wrote: > >Playing a bit with todays linux-next on my jetson, it seems this patch is > >still required for enabling the GPU. Is there anything blocking it (firmware > >not available yet in liux-firmware?) > > I think initially I was waiting for the DRM patch

On PA-RISC machines running in 64-bit mode, uname -m returns `parisc64' instead of `parisc.' Thus, we must sed this to match like a few other platforms. From: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> diff --git a/Makefile b/Makefile index 2b057b8..16a026d 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ include

> I don't know how you proceed to debug FileCheck failures, but for me most of the time I'll have to figure out which "RUN" line fail and try to execute it manually and then remove the FileCheck pipe to get the raw input and then painfully tried to match the FileCheck error to the actual input. Yeah, not very different from what you described here. If I 'm creating or

Hello Ervin, The in-memory cache lookup could be added back into samba-4.1.6 by applying the attached patch, if it could be compiled with Louis how-to steps, perhaps got the chance to make U14.04 be stayed on samba-4. Here is my test, the test-bench is uploading 5000 files and each one is 1MB. The attached patch could improve 15% at case B). Case A) Original samba-4.1.6 will go through

Sorry if I wasn't clear about my use case. In my daily dev work, I do many local "ninja check"s, or "llvm-lit" on a subdirectory as a quick(er) smoke test if I am making changes in that area (e.g. "llvm-lit ../llvm/test/CodeGen"). Nothing wrong here, as indeed nothing changed here. But in case of a test failure, I want to run just that test: bin/llvm-lit

; RISC-V V & VE(*): ; %mask = get.active.lane.mask(%i, %i) ; %evl = min(256, %n - %i) ; MVE/SVE/AVX : ; %mask = get.active.lane.mask(%i, %n) ; %evl = call @llvm.vscale() For VE, we want to do as much predication as possible through %evl and as little as possible with %mask. This has performance implications on VE and RISC-V - VE does not generate a mask from %evl but %evl is

hello hpa, please pull git pull git://brane.itp.tuwien.ac.at/~mattems/klibc.git maks for those changes: Kyle McMartin (1): klibc-utils: add dmesg maximilian attems (2): klibc comment fix fstype: add ocfs2 support with the following diffstat README | 2 usr/Kbuild | 2 usr/kinit/fstype/fstype.c | 15 +++++++

----- Forwarded message from General Stone <generalstone at gmx.net> ----- X-Original-To: maks at sternwelten.at Date: Mon, 2 Jan 2006 14:59:03 +0100 From: General Stone <generalstone at gmx.net> To: maximilian attems <maks at sternwelten.at> Subject: Re: [Logcheck-devel] Bug#344832: correct subject header On Mon, Jan 02, 2006 at 02:09:48PM +0100, maximilian attems wrote: >

On Thu, Jun 18, 2020 at 3:37 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > We’re talking about verbose output right? Verbose isn’t the default. > I'm fairly certain the issue in this thread is just the verbosity of -dump-input=fail. Yes, -vv makes it even more verbose by annotating input lines with good matches, etc., but that's not part of the "new

Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches. And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing first like the LV

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic

Hi Chris, On Thu, Jun 18, 2020 at 1:37 PM Chris Tetreault via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The thing I use normally only shows the first N lines by default (I don’t > know off hand what N is). Honestly, I don’t feel very strongly about the > specific order, but it’s not useful when somebody proposes something on the > list, and nobody voices any dissent