You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(11) |
2
(9) |
3
(11) |
4
(12) |
5
(11) |
|
6
(9) |
7
(13) |
8
(6) |
9
(7) |
10
(7) |
11
(11) |
12
(13) |
|
13
(7) |
14
(6) |
15
(7) |
16
(19) |
17
(20) |
18
(9) |
19
(9) |
|
20
(6) |
21
(7) |
22
(11) |
23
(16) |
24
(14) |
25
(24) |
26
(16) |
|
27
(20) |
28
(58) |
29
(7) |
30
(10) |
31
(15) |
|
|
|
From: Bryan M. <om...@br...> - 2006-08-06 23:33:09
|
Josef, you sir, are a star. :D For now, I have made the function name the same as the file reference number. There is some other tidying up to do but its worth a Beta-02, just to be able to see the output with kcachegrind. One thing of note - I set the context in kcachegrind to be 50 so that in effect, the whole of the file is displayed. The display goes past the end of the file. I shall download the latest source (really not sure what version I am running) and see if I can put a patch together for you to consider. There is also the issue of showing source files that don't get hit at all - maybe there is some scan that could be run from a menu option for that? I don't know. I will look at this as well. The "ignores some files" thing is because I can only have 499 items in a list box. This is going to be a major headache at work where the file count is well above 1000 (and probably at least 2000). I shall have another read through the source for the debug information parsing. I don't want to do anything whilst the program is running but appreciate that if an object unloads, the debug potentially goes with it so I shall have to think about that one. There is a good argument for having a set of bit flags per source file to show executable lines in order to keep the data compact. I really do need to have a look and think on that one though. Thanks for the guidance. I won't announce Beta-02 (but it is on my website now if you (or anyone else) wants to play). I shall cleanup a few more things first then release a Beta-03. Thanks again for your input - it has made my weekend. Bryan "Brain Murders" Meredith Josef Weidendorfer wrote: > On Sunday 06 August 2006 15:08, Bryan Meredith wrote: >>> fn=Unknown >> I changed Covergrind around to output this format (yes, it was simple) >> then passed it into kcachegrind. I was kind of expecting individual >> source files with the event marked as 1 next to all the lines that were >> hit but that didn't happen - I got a single concatenated file that had >> all the source regions in it and no way that I could find to show >> individual files or indeed which line belonged to which source file. > > That one is easy. KCachegrind presents profile information at function > granularity. It was my error to suggest to name everything to be > in function "Unknown". Best would be to provide the function name, but > even providing the file name also as function name at least shows the > data at file name granularity. > > >> I >> also could not stop it from ignoring some of the files. > > No idea why. Can you send me an output showing this problem? > Ah... it could be that KCachegrind only looks at the base name > of a file and not the full path. So if you have 2 source files > with same name in different directories, this could be a problem. > I made this restriction because often, valgrind's debug output > is not able to provide full source paths, depending on debug format > and compiler. > >>> Hmmm... Then your GUI has to read debug info yourself. >> This could indeed be the best way forward as source parsing can be >> fraught (although I was only planning on C/C++ support - the source >> would be available for others to extend if they wish). Again, because of >> the much less restricted environment compared to executing within >> Valgrind, this could well be a simpler task to accomplish. The output >> from "readelf -wl" doesn't seem to be too bad > > Yes. > Valgrind already has this parser for debug line info, both for DWARF and > STABS format. It should be possible to ask for debug info at all text > addresses of an ELF object the first time you see it inside Valgrind. > You would need another event name for the output, e.g. "line with code". > You already can specify derived event types in Callgrinds format (which > should be calculated automatically be KCachegrind). E.g. > > events: lineTouched lineWithCode > event: coverage = lineTouched / lineWithCode > event: notTouched = lineWithCode - lineTouched > ... > > In principle, this works because KCachegrind adds up the counts for e.g. > a function; lets say: 20 lines touched with 30 lines with instructions, > then you get a coverage of 0,67 attributed to this function. > > However, one problem exists: KCachegrind currently does _not_ understand > derived events with "/" in the formula (or "-" for that matter). > But this should be easy to support. > And this is really also interesting to get e.g. "L2 hit ratio". > > Josef > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Josef W. <Jos...@gm...> - 2006-08-06 20:31:51
|
On Sunday 06 August 2006 15:08, Bryan Meredith wrote: > > fn=Unknown > > I changed Covergrind around to output this format (yes, it was simple) > then passed it into kcachegrind. I was kind of expecting individual > source files with the event marked as 1 next to all the lines that were > hit but that didn't happen - I got a single concatenated file that had > all the source regions in it and no way that I could find to show > individual files or indeed which line belonged to which source file. That one is easy. KCachegrind presents profile information at function granularity. It was my error to suggest to name everything to be in function "Unknown". Best would be to provide the function name, but even providing the file name also as function name at least shows the data at file name granularity. > I > also could not stop it from ignoring some of the files. No idea why. Can you send me an output showing this problem? Ah... it could be that KCachegrind only looks at the base name of a file and not the full path. So if you have 2 source files with same name in different directories, this could be a problem. I made this restriction because often, valgrind's debug output is not able to provide full source paths, depending on debug format and compiler. > > Hmmm... Then your GUI has to read debug info yourself. > > This could indeed be the best way forward as source parsing can be > fraught (although I was only planning on C/C++ support - the source > would be available for others to extend if they wish). Again, because of > the much less restricted environment compared to executing within > Valgrind, this could well be a simpler task to accomplish. The output > from "readelf -wl" doesn't seem to be too bad Yes. Valgrind already has this parser for debug line info, both for DWARF and STABS format. It should be possible to ask for debug info at all text addresses of an ELF object the first time you see it inside Valgrind. You would need another event name for the output, e.g. "line with code". You already can specify derived event types in Callgrinds format (which should be calculated automatically be KCachegrind). E.g. events: lineTouched lineWithCode event: coverage = lineTouched / lineWithCode event: notTouched = lineWithCode - lineTouched ... In principle, this works because KCachegrind adds up the counts for e.g. a function; lets say: 20 lines touched with 30 lines with instructions, then you get a coverage of 0,67 attributed to this function. However, one problem exists: KCachegrind currently does _not_ understand derived events with "/" in the formula (or "-" for that matter). But this should be easy to support. And this is really also interesting to get e.g. "L2 hit ratio". Josef |
|
From: Bryan M. <om...@br...> - 2006-08-06 13:21:54
|
(oops - messed up my sender alias - sorry) Josef, thanks for the feedback. I have added comments inline to preserve the context. Bryan "Brain Murders" Meredith Josef Weidendorfer wrote: > On Saturday 05 August 2006 13:52, Bryan Meredith wrote: >> COVERGRIND FILES START >> 0:/home/bryan/covergrind/coregrind/m_trampoline.S >> 1:/home/bryan/c++/qt-x11-opensource-src-4.1.4/examples/widgets/analogclock/../../../include/QtCore/../../src/corelib/global/qglobal.h >> 2:/home/bryan/c++/qt-x11-opensource-src-4.1.4/examples/widgets/analogclock/../../../include/QtCore/../../src/corelib/thread/qatomic.h > >> . >> 0:155-155 > > It actually would be very simple to change this to convert this to > cachegrinds/callgrind format. Callgrinds format has an extension to > exactly provide your file/ID number mapping. And you can load multiple > files to get merging done. However, instead of a range you currently > have to add every touched line seperatly (actually, KCachegrinds > parser and data model knows about ranges, but can not visualize them). > You would use an event type like "lineTouched", and give a 1 for every > line touched in execution: > > events: lineTouched > fl=(0) /home/bryan/covergrind/coregrind/m_trampoline.S > fl=(1) /.../qglobal.h > fl=(2) /.../qatomic.h > ... > fn=Unknown > fl=(0) > 155 1 > 161 1 > ... > fl=(1) > 754 1 > ... I changed Covergrind around to output this format (yes, it was simple) then passed it into kcachegrind. I was kind of expecting individual source files with the event marked as 1 next to all the lines that were hit but that didn't happen - I got a single concatenated file that had all the source regions in it and no way that I could find to show individual files or indeed which line belonged to which source file. I also could not stop it from ignoring some of the files. This will be a problem at work (where I intend to use this) as our codebase is huge and we need to know exactly what is and isn't being tested. This could well all be user error - I have seen kcachegrind in operation several times but never used it in anger myself. > > However: if you stripped the cache simulator from cachegrind (ie. only > do instruction fetches), wouldn't this more or less exactly do what > covergrind is doing now? > It never occurred to me to even look at cachegrind so you may well be correct. >>> If >>> you run a program multiple times, are the coverage results merged? >> In the interests of keeping things simple (and hence lightweight and >> fast) merging of results would be done by the GUI (long way of saying No). > > At least I plan to write a command line merge tool for Callgrinds (and thus, > also Cachegrinds) format; so this would be another advantage to output > this format. See above. I would love to use kcachegrind for the display. It helps me because users are more likely to have that around rather than want to download and build yet another tool (with everything that entails, including me having to hack one together in the first place :P) and it would help the users because they get to use something already familiar to them. > >>> Also, does it give percentage coverage? >> Again, in the GUI, with both the source file and line coverage >> information available, it will be simpler to generate any required >> metrics (another long way of saying No). > > Hmmm... Then your GUI has to read debug info yourself. This could indeed be the best way forward as source parsing can be fraught (although I was only planning on C/C++ support - the source would be available for others to extend if they wish). Again, because of the much less restricted environment compared to executing within Valgrind, this could well be a simpler task to accomplish. The output from "readelf -wl" doesn't seem to be too bad - an awk/perl script would make short work of it, outputting a list of lines that actually had code on them. > Otherwise you have > no way to see whether a non-executed line influences the cover percentage: > it could be actual code or not. > If you want to try parsing the code, keep in mind that this is not only > about empty lines or comments (also for Fortran, ADA, GAS ...), but also > about dead code via #ifdefs). > > Another metric a coverage tool should provide is branch/path coverage. > That is possible, but not easy either. I always considered that to be more of a profiling output than a coverage metric - for pure coverage, you simply hit the line or you don't. I do agree that determining this figure from post analysis would not be trivial. Whereas a user would see the file and notice the difference in counts for the conditional areas, it would not be so easy to pick that up with code. > > Josef > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: <js...@ac...> - 2006-08-06 09:11:47
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-08-06 09:00:02 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 206 tests, 10 stderr failures, 5 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <js...@ac...> - 2006-08-06 02:59:56
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-08-06 03:30:01 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 235 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) |
|
From: Tom H. <th...@cy...> - 2006-08-06 02:57:45
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-06 03:00:03 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 262 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 260 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/tls (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Aug 6 03:28:32 2006 --- new.short Sun Aug 6 03:57:37 2006 *************** *** 8,10 **** ! == 260 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) --- 8,10 ---- ! == 262 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) |
|
From: Tom H. <to...@co...> - 2006-08-06 02:45:44
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-06 03:30:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 237 tests, 4 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |
|
From: Tom H. <th...@cy...> - 2006-08-06 02:28:42
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-06 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccBO9Kvy.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccBO9Kvy.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccBO9Kvy.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccBO9Kvy.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccBO9Kvy.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccBO9Kvy.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccBO9Kvy.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccBO9Kvy.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.21505/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.21505/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.21505/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.21505/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.21505/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 236 tests, 18 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Aug 6 03:23:40 2006 --- new.short Sun Aug 6 03:28:33 2006 *************** *** 6,28 **** ! Regression test results follow ! ! == 236 tests, 18 stderr failures, 0 stdout failures, 0 posttest failures == ! memcheck/tests/addressable (stderr) ! memcheck/tests/badjump (stderr) ! memcheck/tests/describe-block (stderr) ! memcheck/tests/erringfds (stderr) ! memcheck/tests/leak-0 (stderr) ! memcheck/tests/leak-cycle (stderr) ! memcheck/tests/leak-regroot (stderr) ! memcheck/tests/leak-tree (stderr) ! memcheck/tests/match-overrun (stderr) ! memcheck/tests/partial_load_dflt (stderr) ! memcheck/tests/partial_load_ok (stderr) ! memcheck/tests/partiallydefinedeq (stderr) ! memcheck/tests/pointer-trace (stderr) ! memcheck/tests/sigkill (stderr) ! memcheck/tests/stack_changes (stderr) ! memcheck/tests/x86/scalar (stderr) ! memcheck/tests/x86/scalar_supp (stderr) ! memcheck/tests/xml1 (stderr) ! --- 6,27 ---- ! Last 20 lines of verbose log follow echo ! /tmp/ccBO9Kvy.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccBO9Kvy.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccBO9Kvy.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccBO9Kvy.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccBO9Kvy.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccBO9Kvy.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccBO9Kvy.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccBO9Kvy.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' ! make[5]: *** [insn_sse3.o] Error 1 ! rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c ! make[5]: Leaving directory `/tmp/valgrind.21505/valgrind/none/tests/x86' ! make[4]: *** [check-am] Error 2 ! make[4]: Leaving directory `/tmp/valgrind.21505/valgrind/none/tests/x86' ! make[3]: *** [check-recursive] Error 1 ! make[3]: Leaving directory `/tmp/valgrind.21505/valgrind/none/tests' ! make[2]: *** [check-recursive] Error 1 ! make[2]: Leaving directory `/tmp/valgrind.21505/valgrind/none' ! make[1]: *** [check-recursive] Error 1 ! make[1]: Leaving directory `/tmp/valgrind.21505/valgrind' ! make: *** [check] Error 2 |
|
From: Tom H. <th...@cy...> - 2006-08-06 02:25:36
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-06 03:10:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 260 tests, 3 stderr failures, 0 stdout failures, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) |