Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-09 03:15:03 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ..
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-09 03:05:08 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ...
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-09 03:10:04 GMT
Results differ from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... f
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-09 03:00:02
GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests
On Sunday 09 December 2007 00:29, Ashley Pittman wrote:
> On Sat, 2007-12-08 at 19:30 +0100, Julian Seward wrote:
> > We can fix Memcheck by falling back to the reference version, but I'd
> > like to see if there is a way to get the correct behaviour without
> > the extra conditionals.
>
> Perhaps
Author: sewardj
Date: 2007-12-09 02:25:44 + (Sun, 09 Dec 2007)
New Revision: 7288
Log:
Third time lucky, perhaps.
Modified:
trunk/NEWS
trunk/configure.in
Modified: trunk/NEWS
===
--- trunk/NEWS 2007-12-09 02:24:02 UTC (r
Author: sewardj
Date: 2007-12-09 02:24:02 + (Sun, 09 Dec 2007)
New Revision: 7287
Log:
Finalise distro docs for 3.3.0.
Modified:
trunk/ACKNOWLEDGEMENTS
trunk/NEWS
trunk/README
trunk/README_PACKAGERS
Modified: trunk/ACKNOWLEDGEMENTS
===
Author: sewardj
Date: 2007-12-09 02:22:55 + (Sun, 09 Dec 2007)
New Revision: 7286
Log:
Another supp.
Modified:
trunk/glibc-2.34567-NPTL-helgrind.supp
Modified: trunk/glibc-2.34567-NPTL-helgrind.supp
===
--- trunk/glibc-2.345
Author: sewardj
Date: 2007-12-09 02:21:22 + (Sun, 09 Dec 2007)
New Revision: 7285
Log:
Add missing file to tarball.
Modified:
trunk/exp-drd/tests/Makefile.am
Modified: trunk/exp-drd/tests/Makefile.am
===
--- trunk/exp-drd/te
Tom
Thanks for chasing this around. I just committed Nick's patch (r7283).
Could you check out the trunk and verify it works w/ your windows app
now? Overly cautious, I know; but this close to a release ...
J
-
SF.Net e
Author: sewardj
Date: 2007-12-09 02:14:35 + (Sun, 09 Dec 2007)
New Revision: 7284
Log:
Don't do comparisons of (signed) Words by merely subtracting them, as
this does not always produce correct results. Instead use a slower
but correct method. Analogous fix to that applied to m_oset.c by
r72
Author: sewardj
Date: 2007-12-09 02:08:42 + (Sun, 09 Dec 2007)
New Revision: 7283
Log:
Don't do comparisons of (signed) Words by merely subtracting them, as
this does not always produce correct results. Instead use a slower
but correct method. Fixes #147545. (Nick Nethercote, Tom Hughes et
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-09 02:00:01 CET
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ... f
I have an oracle who tells me that the child side of a particular clone()
should not be monitored: valgrind should "let go" of the child
(whether thread or fork) as soon as possible. Waiting for execve(),
to let go as in "--trace-children=no", is not an option.
What is a good way for valgrind let
On Sat, 2007-12-08 at 19:30 +0100, Julian Seward wrote:
> We can fix Memcheck by falling back to the reference version, but I'd
> like to see if there is a way to get the correct behaviour without
> the extra conditionals.
Perhaps you could right shift the value before putting it into the tree?
On Sat, 8 Dec 2007, Christoph Bartoschek wrote:
>> We can fix Memcheck by falling back to the reference version, but I'd
>> like to see if there is a way to get the correct behaviour without
>> the extra conditionals.
>
> I would propose that you use a hashtable for the entries with one of the
> a
Am Samstag, 8. Dezember 2007 schrieb Julian Seward:
> > Yes. The relation established by the comparison function has to be
> > transitive. This is not the case here. Therefore the function should not
> > be used.
> >
> > I've shown how this affects the AVL tree in theory and implementation.
> > Thi
> Yes. The relation established by the comparison function has to be
> transitive. This is not the case here. Therefore the function should not be
> used.
>
> I've shown how this affects the AVL tree in theory and implementation. This
> also fits one fact that Tom gives: There have to be additiona
On Dec 8, 2007 12:02 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
> > On Saturday 08 December 2007 12:10, Christoph Bartoschek wrote:
> >
> > In my opinion the problem is, that you have lost transitivity. Assume Word
>
> If transitivity is lost, then it means fast_cmp is broken.
>
> My current hyp
On Dec 8, 2007 10:43 AM, Julian Seward <[EMAIL PROTECTED]> wrote:
> It's because ISO C says that overflow of signed arithmetic produces
> undefined results, and recent gccs exploit that fact for optimisation
> purposes. Note that overflow of unsigned arithmetic is still well
> defined. If this i
Am Samstag, 8. Dezember 2007 schrieb Julian Seward:
> > On Saturday 08 December 2007 12:10, Christoph Bartoschek wrote:
> >
> > In my opinion the problem is, that you have lost transitivity. Assume
> > Word
>
> If transitivity is lost, then it means fast_cmp is broken.
Yes. The relation establishe
> On Saturday 08 December 2007 12:10, Christoph Bartoschek wrote:
>
> In my opinion the problem is, that you have lost transitivity. Assume Word
If transitivity is lost, then it means fast_cmp is broken.
My current hypothesis is: the ordering of two N-bit signed words X, Y
cannot be correctly es
> > Hmm, yes. Wasn't there a giant storm in a teacup on the gcc list a while
> > back about whether gcc should optimise on the basis that overflow of
> > signed arithmetic is undefined?
>
> I don't understand why the carry bit is important...
It's because ISO C says that overflow of signed arith
Am Samstag, 8. Dezember 2007 schrieb Julian Seward:
> > I don't get the assertion until some more stuff has been added to
> > the tree - the reason is that although the tree is out of order that
> > node is at the root and is therefore found without having to decide
> > which way to go.
>
> But the
24 matches
Mail list logo
