On Friday 22 December 2006 03:03, Paul Brook wrote:
> On Friday 22 December 2006 00:58, Denis Vlasenko wrote:
> > On Tuesday 19 December 2006 23:39, Denis Vlasenko wrote:
> > > There are a lot of 100.00% safe optimizations which gcc
> > > can do. Value range propagation for bitwise operations, for
Hi,
Can an ACL expert please proofread this? This adds ACL support to the
copy_file_preserving function. It compiles fine, but I cannot test it since
none of my systems has ACL support.
2006-12-22 Bruno Haible <[EMAIL PROTECTED]>
* lib/copy-file.c: Include acl.h.
(copy_file_pr
Paul Eggert wrote:
> 2006-12-21 Paul Eggert <[EMAIL PROTECTED]>
>
> * MODULES.html.sh: New module wctype.
> * lib/wctype_.h, m4/wctype.m4, modules/wctype: New files.
> * lib/fnmatch.c: Don't bother to include before
> , since the new wctype module should fix this.
>
On Fri, 2006-12-22 at 12:30 -0500, Robert Dewar wrote:
>
> > Maybe on x86, but on PPC, at least for the (current) Cell's PPU
> > misaligned accesses for most cases unaligned are optimal.
>
> is that true across cache boundaries?
For Cell, crossing the 32byte boundary causes the microcode to hap
Andrew Pinski wrote:
On Fri, 2006-12-22 at 17:08 +, Dave Korn wrote:
Misaligned accesses *kill* your performance!
Maybe on x86, but on PPC, at least for the (current) Cell's PPU
misaligned accesses for most cases unaligned are optimal.
is that true across cache boundaries?
Thanks,
Andr
Dave Korn wrote:
On 22 December 2006 00:59, Denis Vlasenko wrote:
Or this, absolutely typical C code. i386 arch can compare
16 bits at a time here (luckily, no alighment worries on this arch):
Whaddaya mean, no alignment worries? Misaligned accesses *kill* your
performance!
is it really
On Fri, 2006-12-22 at 17:08 +, Dave Korn wrote:
> Misaligned accesses *kill* your performance!
Maybe on x86, but on PPC, at least for the (current) Cell's PPU
misaligned accesses for most cases unaligned are optimal.
Thanks,
Andrew Pinski
On 22 December 2006 00:59, Denis Vlasenko wrote:
> Or this, absolutely typical C code. i386 arch can compare
> 16 bits at a time here (luckily, no alighment worries on this arch):
Whaddaya mean, no alignment worries? Misaligned accesses *kill* your
performance!
I know this doesn't affect c
Paul Eggert wrote:
> Now that we have a wctype module we can simplify some of the other
> modules to just include and depend on the wctype module.
> Here is a proposed patch.
>
> 2006-12-21 Paul Eggert <[EMAIL PROTECTED]>
>
> * lib/mbchar.h: Just include ; the wctype module
> handl
Paul Eggert wrote:
> 2006-12-21 Paul Eggert <[EMAIL PROTECTED]>
>
> * MODULES.html.sh: New module wctype.
> * lib/wctype_.h, m4/wctype.m4, modules/wctype: New files.
> * lib/fnmatch.c: Don't bother to include before
> , since the new wctype module should fix this.
>
Hi,
GNU sed version 4.1b is now implementing its --posix option correctly.
We can use this to avoid portability problems in gnulib-tool.
Please report any breakage that this change introduces :-)
2006-12-22 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (SED): New variable.
U
I added this module now.
> === modules/no-c++ ===
> Description:
> Support for compiling in C mode when CC is set to a C++ compiler.
>
> Files:
> m4/no-c++.m4
>
> Depends-on:
>
> configure.ac:
> gt_NO_CXX
>
> Makefile.am:
>
> Include:
>
Le vendredi 22 décembre 2006 à 12:41 +0100, Yoann Vandoorselaere a
écrit :
> Le vendredi 22 décembre 2006 à 11:55 +0100, Yoann Vandoorselaere a
> écrit :
> > Le vendredi 22 décembre 2006 à 11:31 +0100, Paolo Bonzini a écrit :
> > > >> and it does not work, e.g., on file descriptors. Sorry. :-)
>
Le vendredi 22 décembre 2006 à 11:55 +0100, Yoann Vandoorselaere a
écrit :
> Le vendredi 22 décembre 2006 à 11:31 +0100, Paolo Bonzini a écrit :
> > >> and it does not work, e.g., on file descriptors. Sorry. :-)
> > >
> > > Could you please provide more information about the problem? (Note that
Le vendredi 22 décembre 2006 à 11:31 +0100, Paolo Bonzini a écrit :
> >> and it does not work, e.g., on file descriptors. Sorry. :-)
> >
> > Could you please provide more information about the problem? (Note that
> > the current CVS version doesn't work on socket, which is not much
> > better).
and it does not work, e.g., on file descriptors. Sorry. :-)
Could you please provide more information about the problem? (Note that
the current CVS version doesn't work on socket, which is not much
better). Providing your test case would help.
Just open a file, and poll it. It should give
Le vendredi 22 décembre 2006 à 10:48 +0100, Paolo Bonzini a écrit :
> >>> I don't remember if it was Paul or Bruno who suggested that POLLHUP
> >>> does not increase the return value. What do you think?
> >
> > Attached is an improved version that should conform more to GnuLib
> > coding standard
I don't remember if it was Paul or Bruno who suggested that POLLHUP
does not increase the return value. What do you think?
Attached is an improved version that should conform more to GnuLib
coding standard.
Hi Yoann,
unfortunately the patch is wrong, as it never sets POLLHUP on Mac OS X
a
Here's the patch I installed to gnulib, to sync it from the
mktime patch in Autoconf.
2006-12-22 Paul Eggert <[EMAIL PROTECTED]>
* m4/mktime.m4 (AC_FUNC_MKTIME): Sync from Autoconf.
Include , and use its INT_MAX to rewrite the
j loop so that it does not overflow 'int'.
I installed the following into Autoconf to fix the Autoconf side of
the problem.
2006-12-22 Paul Eggert <[EMAIL PROTECTED]>
* lib/autoconf/functions.m4 (AC_FUNC_MKTIME):
Include , and use its INT_MAX to rewrite the
j loop so that it does not overflow 'int'. Problem repo
Or you can do, since elsewhere in the code you compute time_t_max:
for (j = 1; j <= time_t_max / 2 + 1; j *= 2)
No, this does not work. It would work to have:
for (j = 1;;)
{
if (j > time_t_max / 2)
break;
j *= 2;
}
Oops.
Paolo
int j;
for (j = 1; 0 < j; j *= 2)
if (! bigtime_test (j))
return 1;
Here it is obvious to a programmer that the comparison is
intended to do overflow checking, even though the test
controls the loop.
Well, it's not to me. :-)
Another question for the GCC expert
22 matches
Mail list logo
