search for: 764,13

..., > with preprocessed source if appropriate. I can't reproduce this on darwin-ppc or darwin-x86, so this is a stab in the dark. Can you try this patch: =================================================================== --- i386.h (revision 112156) +++ i386.h (working copy) @@ -764,7 +764,13 @@ extern int x86_prefetch_sse; /* target machine storage layout */ +/* APPLE LOCAL begin LLVM */ +#ifdef ENABLE_LLVM +#define LONG_DOUBLE_TYPE_SIZE 64 +#else #define LONG_DOUBLE_TYPE_SIZE 80 +#endif +/* APPLE LOCAL end LLVM */ /* Set the value of FLT_EVAL_METHOD in float.h. Wh...

Chris Lattner wrote: > Here's a new snapshot of the front-end: > http://nondot.org/sabre/2006-03-14-llvm-gcc-4.tar.gz > > This: > > 1. Fixes the inline asm problem you have above. > 2. Includes patches to make it better on Alpha's (thanks to patches by > Andrew Lenharth). > 3. Sync's it up with debug info changes in LLVM CVS (by Jim Laskey). > 4.

>> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > There's some confusion with --enable-llvm configure parameter. I've built > LLVM to a separate build dir. The source is ~ghost/Work/llvm-cvs and build > dir is /space/p2/ghost/build/llvm-cvs ... > So, it seems like, at the same time: > > 1. buildir

...++----------------------- 4 files changed, 21 insertions(+), 69 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 4b4b0b4..8f689f1 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -764,13 +764,18 @@ nv_crtc_gamma_load(struct drm_crtc *crtc) struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc); struct drm_device *dev = nv_crtc->base.dev; struct rgb { uint8_t r, g, b; } __attribute__((packed)) *rgbs; + u16 *r, *g, *b; int i; rgbs = (struct rgb *)nv04_display(dev)->mo...

...+++---------------------- 4 files changed, 22 insertions(+), 69 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 4b4b0b4..8f689f1 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -764,13 +764,18 @@ nv_crtc_gamma_load(struct drm_crtc *crtc) struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc); struct drm_device *dev = nv_crtc->base.dev; struct rgb { uint8_t r, g, b; } __attribute__((packed)) *rgbs; + u16 *r, *g, *b; int i; rgbs = (struct rgb *)nv04_display(dev)->mo...

...+++---------------------- 4 files changed, 22 insertions(+), 69 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index f562824..b233412 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -764,13 +764,18 @@ nv_crtc_gamma_load(struct drm_crtc *crtc) struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc); struct drm_device *dev = nv_crtc->base.dev; struct rgb { uint8_t r, g, b; } __attribute__((packed)) *rgbs; + u16 *r, *g, *b; int i; rgbs = (struct rgb *)nv04_display(dev)->mo...

...--------------- 4 files changed, 22 insertions(+), 69 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 4b4b0b496262..8f689f1f6122 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -764,13 +764,18 @@ nv_crtc_gamma_load(struct drm_crtc *crtc) struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc); struct drm_device *dev = nv_crtc->base.dev; struct rgb { uint8_t r, g, b; } __attribute__((packed)) *rgbs; + u16 *r, *g, *b; int i; rgbs = (struct rgb *)nv04_display(dev)->mo...

...opriate. > > I can't reproduce this on darwin-ppc or darwin-x86, so this is a > stab in the dark. Can you try this patch: > > =================================================================== > --- i386.h (revision 112156) > +++ i386.h (working copy) > @@ -764,7 +764,13 @@ extern int x86_prefetch_sse; > > > /* target machine storage layout */ > > +/* APPLE LOCAL begin LLVM */ > +#ifdef ENABLE_LLVM > +#define LONG_DOUBLE_TYPE_SIZE 64 > +#else > #define LONG_DOUBLE_TYPE_SIZE 80 > +#endif > +/* APPLE LOCAL end LLVM */ >...

...ord change required but no " + "TTY available"); /* Fork the child. */ if ((pid = fork()) == 0) { @@ -726,6 +731,7 @@ socklen_t fromlen; struct sockaddr_storage from; struct passwd * pw = s->pw; + int password_changed = 0; pid_t pid = getpid(); /* @@ -758,6 +764,13 @@ print_pam_messages(); do_pam_chauthtok(); } +#else + buffer_append(&expiremsg, "\0", 1); + if (password_change_required) { + printf("%s\n", (char *)buffer_ptr(&expiremsg)); + fflush(stdout); + password_changed = do_tty_change_password(pw); + } #endif...

...ord change required but no " + "TTY available"); /* Fork the child. */ if ((pid = fork()) == 0) { @@ -726,6 +731,7 @@ socklen_t fromlen; struct sockaddr_storage from; struct passwd * pw = s->pw; + int password_changed = 0; pid_t pid = getpid(); /* @@ -758,6 +764,13 @@ print_pam_messages(); do_pam_chauthtok(); } +#else + buffer_append(&expiremsg, "\0", 1); + if (password_change_required) { + printf("%s\n", (char *)buffer_ptr(&expiremsg)); + fflush(stdout); + password_changed = do_tty_change_password(pw); + } #endif...

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 and 3 are enough to make the atmel-hlcdc driver do what I need. The rest is

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 and 3 are enough to make the atmel-hlcdc driver do what I need. The rest is

...ock); - list_for_each_safe(iter, tmp, &nn->nn_status_list) { - nsw = list_entry(iter, struct o2net_status_wait, ns_node_item); + list_for_each_entry_safe(nsw, tmp, &nn->nn_status_list, ns_node_item) { o2net_complete_nsw_locked(nn, nsw, O2NET_ERR_DIED, 0); num_kills++; } @@ -764,13 +762,10 @@ EXPORT_SYMBOL_GPL(o2net_register_handler void o2net_unregister_handler_list(struct list_head *list) { - struct list_head *pos, *n; - struct o2net_msg_handler *nmh; + struct o2net_msg_handler *nmh, *n; write_lock(&o2net_handler_lock); - list_for_each_safe(pos, n, list) { -...

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 through 5 are enough to make the atmel-hlcdc driver do what I need. The rest

When running on PowerPC, we don''t have native PIO support. There are a few hacks around to enable PIO access on PowerPC nevertheless. The most typical one is the isa-mmio device. It takes MMIO requests and converts them to PIO requests on the (QEMU internal) PIO bus. This however is not how real hardware works and it limits us in the ability to spawn eventfd''s on PIO ports

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. Boris and Daniel, was this approximately what you had in mind? I have obviously not tested all of this with more than a compile, but the first patch is

Hi! While trying to get CLUT support for the atmel_hlcdc driver, and specifically for the emulated fbdev interface, I received some push-back that my feeble in-driver attempts should be solved by the core. This is my attempt to do it right. I have obviously not tested all of this with more than a compile, but patches 1 and 3 are enough to make the atmel-hlcdc driver do what I need (when patched