|
From: Nicholas N. <nj...@ca...> - 2003-02-25 09:49:50
|
Hi, As per subject... the bug has been introduced within the last few days, I think, because I didn't have it in my workspace copy until I updated and rebuilt just then. To see, run one of: $PREFIX/bin/vg_regtest --all $PREFIX/bin/vg_regtest memcheck $PREFIX/bin/vg_regtest memcheck/tests/new_override within the top level valgrind/ directory. I don't see how any of my recent commits could have caused this, so I'm brazenly assuming it's not my fault until proven otherwise... :) N |
|
From: Julian S. <js...@ac...> - 2003-02-25 23:26:47
|
[Dirk .. (1) thanks for fixing 'make install'. However ...
(2) pls read at least the last para
.. more fallout from recent changes?]
Mystery solved ... possibly a side effect of fixing 'make install'.
> As per subject... the bug has been introduced within the last few days, I
> think, because I didn't have it in my workspace copy until I updated and
> rebuilt just then.
>
> To see, run one of:
>
> $PREFIX/bin/vg_regtest --all
> $PREFIX/bin/vg_regtest memcheck
> $PREFIX/bin/vg_regtest memcheck/tests/new_override
>
> within the top level valgrind/ directory.
>
> I don't see how any of my recent commits could have caused this, so I'm
> brazenly assuming it's not my fault until proven otherwise... :)
Sigh. Curiously, it also fails on SuSE 8.1. The .stderr.exp says there
should be an uninit-var error at line 25. The .stderr.out mentions
no such.
Reading the assembly for main, with and without -O is revealing.
for (i = 0; i < 2; i++) {
if (toto[i].a) {
j++;
}
// main returns now
With -O and above, gcc sees that j is dead after the loop, and converts
it to
movl $0, %eax
.L15:
incl %eax
cmpl $1, %eax
jle .L15
ie
for (i = 0; i < 2; i++) {
}
[Why it doesn't then unroll the loop and change this to "i = 2",
I don't know. But anyway ...]
So it's no wonder no error is reported for me.
Rerunning the test without -O does indeed get an error reported.
And indeed I see that the test is built with -O2 -g.
Have a look at rev 1.6 of valgrind/memcheck/tests/Makefile.am.
It changes the flag handling for the tests (I guess) and I bet
that causes -O2 to be passed to the test compilations. Which
I guess it shouldn't be. Didn't we have a no-optimisation policy
for regressions, to try and ensure gcc didn't optimise stuff away?
Ha .. more clarity. In memcheck/tests, it is only "mismatches" and
"new_override" which are compiled with -g -O2. And these are
exactly the C++ ones.
So I wonder if, in valgrind/memcheck/tests/Makefile.am,
the renaming of CXXFLAGS to AM_CXXFLAGS didn't have the desired
effect?
J
|
|
From: Dirk M. <dm...@gm...> - 2003-02-26 00:14:33
|
On Die, 25 Feb 2003, Julian Seward wrote: > So I wonder if, in valgrind/memcheck/tests/Makefile.am, > the renaming of CXXFLAGS to AM_CXXFLAGS didn't have the desired > effect? Thats correct. $(AM_CXXFLAGS) is _before_ CXXFLAGS, so a later flags (like CXXFLAGS) overwrites it. Sorry, this was introduced by me then. However, CXXFLAGS is not really supposed to get set in a makefile, its a "user flag" (something that the user should set, i.e. by doing CXXFLAGS="-march=pentium42" make ) However in this case it is desired to not compile with -O2. something is fishy here. have to look into it. -- Dirk (received 274 mails today) |
|
From: Jeremy F. <je...@go...> - 2003-02-26 00:40:33
|
On Tue, 2003-02-25 at 15:34, Julian Seward wrote:
> [Why it doesn't then unroll the loop and change this to "i = 2",
> I don't know. But anyway ...]
gcc explicitly avoids optimising away empty loops since they might be
being used for delays.
J
|
|
From: Julian S. <js...@ac...> - 2003-02-25 23:52:56
|
Ok, committed a fix which I think should work for you. It still fails on my box, but now for totally tedious reasons: *** new_override.stderr.exp 2002-09-23 11:21:53.000000000 +0000 --- new_override.stderr.out 2003-02-25 23:51:47.000000000 +0000 *************** *** 8,9 **** ! malloc/free: in use at exit: 32 bytes in 1 blocks. ! malloc/free: 1 allocs, 0 frees, 32 bytes allocated. --- 8,9 ---- ! malloc/free: in use at exit: 112 bytes in 3 blocks. ! malloc/free: 3 allocs, 0 frees, 112 bytes allocated. ie presumably glibc differences between your system and mine cause that. ----------------- Can you just check that the make system still works for you, ie make, make clean, make install, make dist, make distcheck, are ok? Looks OK at this end. J On Tuesday 25 February 2003 9:49 am, Nicholas Nethercote wrote: > Hi, > > As per subject... the bug has been introduced within the last few days, I > think, because I didn't have it in my workspace copy until I updated and > rebuilt just then. > > To see, run one of: > > $PREFIX/bin/vg_regtest --all > $PREFIX/bin/vg_regtest memcheck > $PREFIX/bin/vg_regtest memcheck/tests/new_override > > within the top level valgrind/ directory. > > I don't see how any of my recent commits could have caused this, so I'm > brazenly assuming it's not my fault until proven otherwise... :) > > N > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@ca...> - 2003-02-26 10:21:09
|
On Wed, 26 Feb 2003, Julian Seward wrote: > It still fails on my box, but now for totally tedious reasons: > > *** new_override.stderr.exp 2002-09-23 11:21:53.000000000 +0000 > --- new_override.stderr.out 2003-02-25 23:51:47.000000000 +0000 > *************** > *** 8,9 **** > ! malloc/free: in use at exit: 32 bytes in 1 blocks. > ! malloc/free: 1 allocs, 0 frees, 32 bytes allocated. > --- 8,9 ---- > ! malloc/free: in use at exit: 112 bytes in 3 blocks. > ! malloc/free: 3 allocs, 0 frees, 112 bytes allocated. > > ie presumably glibc differences between your system and mine > cause that. I added a stderr filter that removes the numbers for that test... it should work for you now. > Can you just check that the make system still works for you, ie > make, make clean, make install, make dist, make distcheck, are > ok? Looks OK at this end. Alles klar. N |