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
(14) |
2
(8) |
3
(7) |
|
4
(7) |
5
(7) |
6
(6) |
7
(11) |
8
(10) |
9
(14) |
10
(10) |
|
11
(13) |
12
(15) |
13
(6) |
14
(8) |
15
(6) |
16
(6) |
17
(6) |
|
18
(6) |
19
(11) |
20
(15) |
21
(14) |
22
(11) |
23
(7) |
24
(17) |
|
25
(14) |
26
(28) |
27
(21) |
28
(23) |
29
(21) |
30
(17) |
31
(8) |
|
From: Nicholas N. <nj...@cs...> - 2007-03-24 23:48:29
|
On Sat, 24 Mar 2007, xiaoming gu wrote: > I get the following failed assertion problem when I'm trying to profile some > program > using a new tool based on valgrind. > =================== > valgrind: ../../valgrind-3.2.2-reda/coregrind/m_threadstate.c:63 > (vgPlain_get_ThreadState): Assertion 'VG_(threads)[tid].tid == tid' failed. > In get_ThreadState. > =================== > > I aslo get the following information from debugging it. > =================== > #0 vgPlain_get_ThreadState (tid=1) > at ../../valgrind-3.2.2-reda/coregrind/m_threadstate.c:63 > #1 0x38010aa4 in sync_signalhandler (sigNo=11, info=0x8907ab6c, > uc=0x8907abec) > at ../../valgrind-3.2.2-reda/coregrind/m_signals.c:1731 > #2 0x3800e500 in vgPlain_redir_notify_new_SegInfo () > Previous frame inner to this frame (corrupt stack?) > =================== > > After try my best, I still don't know where is the bug. I use system calls > provided by > valgrind itself. And when I try other programs with this new tool there is > no such a > failed assertion. Please give me some directions if you have the same > problem before. Have you tried using debugging printfs to find out the incorrect value? Have you tried running other Valgrind tools (--tool=none, memcheck, cachegrind) to see if the same thing happens? Nick |
|
From: Nicholas N. <nj...@cs...> - 2007-03-24 23:46:07
|
On Sat, 24 Mar 2007, Vince Weaver wrote: > I do wonder if any of the compiler vendors noticed this problem with art.. > you could in theory make your compiler look better on the FP score by > having art finish in half the time if you made sure it ran in 64-bit > rather than 80-bit mode on x86... Surely the SPEC output checking would catch this, if you are doing proper, reportable runs? Nick |
|
From: xiaoming g. <xia...@gm...> - 2007-03-24 19:53:07
|
Hi, all.
I get the following failed assertion problem when I'm trying to profile some
program
using a new tool based on valgrind.
===================
valgrind: ../../valgrind-3.2.2-reda/coregrind/m_threadstate.c:63
(vgPlain_get_ThreadState): Assertion 'VG_(threads)[tid].tid == tid' failed.
In get_ThreadState.
===================
I aslo get the following information from debugging it.
===================
#0 vgPlain_get_ThreadState (tid=1)
at ../../valgrind-3.2.2-reda/coregrind/m_threadstate.c:63
#1 0x38010aa4 in sync_signalhandler (sigNo=11, info=0x8907ab6c,
uc=0x8907abec)
at ../../valgrind-3.2.2-reda/coregrind/m_signals.c:1731
#2 0x3800e500 in vgPlain_redir_notify_new_SegInfo ()
Previous frame inner to this frame (corrupt stack?)
===================
After try my best, I still don't know where is the bug. I use system calls
provided by
valgrind itself. And when I try other programs with this new tool there is
no such a
failed assertion. Please give me some directions if you have the same
problem before.
Xiaoming Gu
|
|
From: Vince W. <vi...@cs...> - 2007-03-24 18:27:40
|
On Sat, 24 Mar 2007, Julian Seward wrote: > > > On Saturday 24 March 2007 08:23, Bart Van Assche wrote: > > > > My opinion is that the art program is flawed: it is never a good idea to > > compare floating point numbers with the "==" or "!=" operator. [...] > > I agree, floating point comparison is not good. On the other hand, > SPEC CPU is designed to be portable and I would be amazed if the SPEC > folks had not looked into these problems in depth. Perhaps they > fixed all problems they encountered in testing, but this one did not > happen at that time, and it is only triggered by Valgrind's extra > inaccuracy on x86. Who knows. While you would think SPEC would have done a good job picking portable benchmarks, in actual fact they are a mess. What passed for acceptable code ~1998 when the spec2000 codes were frozen just wouldn't fly today. They've had to release a number of service packs along the way because probably at least half the original spec2k code release won't compile with a gcc more recent than 2.8 or so. Even now, with the most recent spec2k release, you can't compile the 'vortex' benchmark with optimizations turned on with gcc 4.0 or it will crash on x86-linux. I do wonder if any of the compiler vendors noticed this problem with art.. you could in theory make your compiler look better on the FP score by having art finish in half the time if you made sure it ran in 64-bit rather than 80-bit mode on x86... For my purposes I hacked the art code and added a few lines of code at the beginning to force the x87 fpu state to be FPU_DOUBLE (instead of FPU_EXTENDED) and that is enough to make the valgrind runs match the actual perf counter runs. >From what I gather from the document I linked to earlier by Whiteley, it is only Linux x86 that even shows this behavior; other OSes like x86-BSD and Windows don't enable extended mode by default. Thanks for all the help looking into this, Vince |
|
From: Julian S. <js...@ac...> - 2007-03-24 12:18:50
|
> On Saturday 24 March 2007 08:23, Bart Van Assche wrote: > > My opinion is that the art program is flawed: it is never a good idea to > compare floating point numbers with the "==" or "!=" operator. [...] I agree, floating point comparison is not good. On the other hand, SPEC CPU is designed to be portable and I would be amazed if the SPEC folks had not looked into these problems in depth. Perhaps they fixed all problems they encountered in testing, but this one did not happen at that time, and it is only triggered by Valgrind's extra inaccuracy on x86. Who knows. J |
|
From: <js...@ac...> - 2007-03-24 11:50:20
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-03-24 09:00:02 GMT 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 == 219 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) 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: Bart V. A. <bar...@gm...> - 2007-03-24 08:23:18
|
On 3/24/07, Nicholas Nethercote <nj...@cs...> wrote: > > > To augment Julian's comment: for x86, Valgrind simulates a machine with > 64-bit FP registers. The important question here: is that 64-bit > implementation correct? Ie. is 'art' relying on the extra 16 bits of > accuracy? If so, then 'art' is arguably (some would disagree) at fault, > because it's doing non-portable things. Given that it is in SPEC, that > would be surprising. Or, Valgrind's 64-bit FP implementation may have > bugs. > My opinion is that the art program is flawed: it is never a good idea to compare floating point numbers with the "==" or "!=" operator. Floating point numbers must be compared via fabs(... - ...) < ... or fabs(... - ...) > ... This is something you can find in any decent FAQ about numerical computing. Bart. |
|
From: Tom H. <th...@cy...> - 2007-03-24 03:31:15
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-03-24 03:15:01 GMT 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 == 256 tests, 27 stderr failures, 1 stdout failure, 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-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (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/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-03-24 03:23:30
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2007-03-24 03:10:05 GMT 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 == 291 tests, 4 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) |
|
From: Tom H. <th...@cy...> - 2007-03-24 03:18:59
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-03-24 03:05:05 GMT 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 == 291 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-03-24 03:12:10
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-03-24 03:00:03 GMT 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 == 293 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Vince W. <vi...@cs...> - 2007-03-24 02:21:03
|
> If this comparison is not in a an inner loop, can you do some nasty > kludge like masking off the lowest couple of mantissa bits before > doing the comparison? I was thinking about trying that as a last resort. I came across an interesting paper: http://www.wrcad.com/linux_numerics.txt Maybe I can try forcing art to use FPU_DOUBLE mode instead of FPU_EXTENDED in the manner described in the paper... Vince |
|
From: Julian S. <js...@ac...> - 2007-03-24 02:10:22
|
On Friday 23 March 2007 23:00, Nicholas Nethercote wrote: > On Fri, 23 Mar 2007, Julian Seward wrote: > > Valgrind's handling of x86 FP is something of a kludge. In short > > it regards all operations internally as 64-bit, to increase commonality > > of Valgrind's internals with other platforms and reduce overall > > engineering effort. Unfortunately this can give rise to the kinds > > of problem you saw. Fixing it properly would take a significant amount > > of time hacking around the internals of VEX. > > To augment Julian's comment: for x86, Valgrind simulates a machine with > 64-bit FP registers. The important question here: is that 64-bit > implementation correct? Having looked at Vince's test case, I didn't see any place where Valgrind incorrectly double-rounds the value. At least that's one good thing, even though it doesn't help Vince. I did notice that valgrind's register allocator was using 64-bit loads/ stores to spill FP registers, which isn't really right -- it means a spill-reload event isn't "transparent" to the value. I fixed it to do 80-bit spilling. This made no difference whatsoever to the big FP suite I use for testing (GNU gsl 1.6), alas. J |
|
From: Julian S. <js...@ac...> - 2007-03-24 02:05:55
|
> Unfortunately for me the machine I am using to do the performance > counter measurements is an older pentium3 that doesn't have sse2 support, > so I am going to have to find another way to work around this for now. If this comparison is not in a an inner loop, can you do some nasty kludge like masking off the lowest couple of mantissa bits before doing the comparison? J |
|
From: Vince W. <vi...@cs...> - 2007-03-24 01:52:20
|
> To augment Julian's comment: for x86, Valgrind simulates a machine with > 64-bit FP registers. The important question here: is that 64-bit > implementation correct? Ie. is 'art' relying on the extra 16 bits of > accuracy? If so, then 'art' is arguably (some would disagree) at fault, > because it's doing non-portable things. Given that it is in SPEC, that > would be surprising. Or, Valgrind's 64-bit FP implementation may have bugs. I think the problem does lie with 'art', but unfortunately it's a bit late to do anything about this (it's the spec2k version of art, I don't think it is even included in spec2k6). I've done the same experiment with art compiled with -msse2 and found that the problem goes away; since the sse2 floating point code only uses 64-bit math this seems to indicate valgrind is behaving properly with regards to 64-bit math. Unfortunately for me the machine I am using to do the performance counter measurements is an older pentium3 that doesn't have sse2 support, so I am going to have to find another way to work around this for now. Thanks for the help, Vince |
|
From: Nicholas N. <nj...@cs...> - 2007-03-24 01:19:45
|
On Fri, 23 Mar 2007, Julian Seward wrote: > Valgrind's handling of x86 FP is something of a kludge. In short > it regards all operations internally as 64-bit, to increase commonality > of Valgrind's internals with other platforms and reduce overall > engineering effort. Unfortunately this can give rise to the kinds > of problem you saw. Fixing it properly would take a significant amount > of time hacking around the internals of VEX. To augment Julian's comment: for x86, Valgrind simulates a machine with 64-bit FP registers. The important question here: is that 64-bit implementation correct? Ie. is 'art' relying on the extra 16 bits of accuracy? If so, then 'art' is arguably (some would disagree) at fault, because it's doing non-portable things. Given that it is in SPEC, that would be surprising. Or, Valgrind's 64-bit FP implementation may have bugs. Nick |
|
From: <js...@ac...> - 2007-03-24 01:16:25
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-03-24 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 ... failed Regression test results follow == 226 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |