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
(12) |
2
(10) |
3
(13) |
4
(10) |
|
5
(8) |
6
(7) |
7
(8) |
8
(8) |
9
(7) |
10
(8) |
11
(8) |
|
12
(9) |
13
(8) |
14
(17) |
15
(13) |
16
(13) |
17
(11) |
18
(11) |
|
19
(14) |
20
(11) |
21
(8) |
22
(17) |
23
(10) |
24
(9) |
25
(10) |
|
26
(12) |
27
(11) |
28
(10) |
29
(8) |
30
(7) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2006-11-23 22:59:20
|
On Thu, 23 Nov 2006, Julian Seward wrote: > In principle I agree with Josef, but I have a different suggestion > for implementation. The core module m_machine exists precisely to > give a convenient place to record/discover various aspects of the > CPU we are running on. And so I think the cache detection stuff > should all be moved in there. Maybe, but Josef's change is simpler and more likely to occur... N |
|
From: Julian S. <js...@ac...> - 2006-11-23 16:39:26
|
In principle I agree with Josef, but I have a different suggestion for implementation. The core module m_machine exists precisely to give a convenient place to record/discover various aspects of the CPU we are running on. And so I think the cache detection stuff should all be moved in there. J On Thursday 23 November 2006 16:10, Josef Weidendorfer wrote: > On Thursday 23 November 2006 14:04, sv...@va... wrote: > > Author: weidendo > > Date: 2006-11-23 13:04:30 +0000 (Thu, 23 Nov 2006) > > New Revision: 6369 > > > > Log: > > Cachegrind/Callgrind: Fix cache parameter detection > > I think we really should get rid of the total duplication > of code in cg-amd64.c and cg-x86.c. They are currently > more or less exactly the same. > > Whatever new additions are needed, they will be needed for > both files, as any 64bit x86 processor can also run in > 32bit mode. > > How to do it best? > I suggest moving the code into a new cg-x86-amd64.c and > include it both in cg-amd64.c and cg-x86.c. > > 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-11-23 16:11:05
|
On Thursday 23 November 2006 14:04, sv...@va... wrote: > Author: weidendo > Date: 2006-11-23 13:04:30 +0000 (Thu, 23 Nov 2006) > New Revision: 6369 > > Log: > Cachegrind/Callgrind: Fix cache parameter detection I think we really should get rid of the total duplication of code in cg-amd64.c and cg-x86.c. They are currently more or less exactly the same. Whatever new additions are needed, they will be needed for both files, as any 64bit x86 processor can also run in 32bit mode. How to do it best? I suggest moving the code into a new cg-x86-amd64.c and include it both in cg-amd64.c and cg-x86.c. Josef |
|
From: <sv...@va...> - 2006-11-23 15:14:22
|
Author: sewardj
Date: 2006-11-23 15:14:18 +0000 (Thu, 23 Nov 2006)
New Revision: 6370
Log:
Fix compilation warning, and partially de-leak.
Modified:
trunk/auxprogs/mpiwrap_type_test.c
Modified: trunk/auxprogs/mpiwrap_type_test.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/auxprogs/mpiwrap_type_test.c 2006-11-23 13:04:30 UTC (rev 6369)
+++ trunk/auxprogs/mpiwrap_type_test.c 2006-11-23 15:14:18 UTC (rev 6370)
@@ -8,6 +8,7 @@
=20
#include <stdio.h>
#include <stdlib.h>
+#include <string.h>
#include <assert.h>
#include "mpi.h"
#include "../memcheck/memcheck.h"
@@ -208,6 +209,10 @@
for (i =3D 0; i < ub; i++)
printf("%c", characterise(rbuf[i]));
printf("\n");
+
+ free(sbuf);
+ free(rbuf);
+ free(rbuf_walk);
}
=20
=20
|
|
From: <sv...@va...> - 2006-11-23 13:04:36
|
Author: weidendo
Date: 2006-11-23 13:04:30 +0000 (Thu, 23 Nov 2006)
New Revision: 6369
Log:
Cachegrind/Callgrind: Fix cache parameter detection
On Intel processors, CPUIDs cache parameter code 0x49 is
reused both for L2 and L3 parameters.
Thanks to Ulrich Drepper.
Modified:
trunk/cachegrind/cg-amd64.c
trunk/cachegrind/cg-x86.c
Modified: trunk/cachegrind/cg-amd64.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/cachegrind/cg-amd64.c 2006-11-22 21:07:10 UTC (rev 6368)
+++ trunk/cachegrind/cg-amd64.c 2006-11-23 13:04:30 UTC (rev 6369)
@@ -52,11 +52,16 @@
=20
/* Intel method is truly wretched. We have to do an insane indexing int=
o an
* array of pre-defined configurations for various parts of the memory
- * hierarchy.=20
+ * hierarchy.
+ * According to Intel Processor Identification, App Note 485.
*/
static
Int Intel_cache_info(Int level, cache_t* I1c, cache_t* D1c, cache_t* L2c=
)
{
+ Int cpuid1_eax;
+ Int cpuid1_ignore;
+ Int family;
+ Int model;
UChar info[16];
Int i, trials;
Bool L2_found =3D False;
@@ -68,6 +73,12 @@
return -1;
}
=20
+ /* family/model needed to distinguish code reuse (currently 0x49) */
+ VG_(cpuid)(1, &cpuid1_eax, &cpuid1_ignore,
+ &cpuid1_ignore, &cpuid1_ignore);
+ family =3D (((cpuid1_eax >> 20) & 0xff) << 4) + ((cpuid1_eax >> 8) & =
0xf);
+ model =3D (((cpuid1_eax >> 16) & 0xf) << 4) + ((cpuid1_eax >> 4) & 0=
xf);
+
VG_(cpuid)(2, (Int*)&info[0], (Int*)&info[4],=20
(Int*)&info[8], (Int*)&info[12]);
trials =3D info[0] - 1; /* AL register - bits 0..7 of %eax */
@@ -110,7 +121,7 @@
=20
case 0x22: case 0x23: case 0x25: case 0x29: case 0x46: case 0x47:
VG_(message)(Vg_DebugMsg,=20
- "warning: L3 cache detected but ignored\n");
+ "warning: L3 cache detected but ignored");
break;
=20
/* These are sectored, whatever that means */
@@ -129,7 +140,14 @@
case 0x43: *L2c =3D (cache_t) { 512, 4, 32 }; L2_found =3D True; =
break;
case 0x44: *L2c =3D (cache_t) { 1024, 4, 32 }; L2_found =3D True; =
break;
case 0x45: *L2c =3D (cache_t) { 2048, 4, 32 }; L2_found =3D True; =
break;
- case 0x49: *L2c =3D (cache_t) { 4096,16, 64 }; L2_found =3D True; =
break;
+ case 0x49:
+ if ((family =3D=3D 15) && (model =3D=3D 6))
+ /* On Xeon MP (family F, model 6), this is for L3 */
+ VG_(message)(Vg_DebugMsg,=20
+ "warning: L3 cache detected but ignored\n");
+ else
+ *L2c =3D (cache_t) { 4096, 16, 64 }; L2_found =3D True;
+ break;
=20
/* These are sectored, whatever that means */
case 0x60: *D1c =3D (cache_t) { 16, 8, 64 }; break; /* secto=
red */
Modified: trunk/cachegrind/cg-x86.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/cachegrind/cg-x86.c 2006-11-22 21:07:10 UTC (rev 6368)
+++ trunk/cachegrind/cg-x86.c 2006-11-23 13:04:30 UTC (rev 6369)
@@ -52,11 +52,16 @@
=20
/* Intel method is truly wretched. We have to do an insane indexing int=
o an
* array of pre-defined configurations for various parts of the memory
- * hierarchy.=20
+ * hierarchy.
+ * According to Intel Processor Identification, App Note 485.
*/
static
Int Intel_cache_info(Int level, cache_t* I1c, cache_t* D1c, cache_t* L2c=
)
{
+ Int cpuid1_eax;
+ Int cpuid1_ignore;
+ Int family;
+ Int model;
UChar info[16];
Int i, trials;
Bool L2_found =3D False;
@@ -68,6 +73,12 @@
return -1;
}
=20
+ /* family/model needed to distinguish code reuse (currently 0x49) */
+ VG_(cpuid)(1, &cpuid1_eax, &cpuid1_ignore,
+ &cpuid1_ignore, &cpuid1_ignore);
+ family =3D (((cpuid1_eax >> 20) & 0xff) << 4) + ((cpuid1_eax >> 8) & =
0xf);
+ model =3D (((cpuid1_eax >> 16) & 0xf) << 4) + ((cpuid1_eax >> 4) & 0=
xf);
+
VG_(cpuid)(2, (Int*)&info[0], (Int*)&info[4],=20
(Int*)&info[8], (Int*)&info[12]);
trials =3D info[0] - 1; /* AL register - bits 0..7 of %eax */
@@ -109,7 +120,8 @@
VG_(tool_panic)("IA-64 cache detected?!");
=20
case 0x22: case 0x23: case 0x25: case 0x29: case 0x46: case 0x47:
- VG_(message)(Vg_DebugMsg, "warning: L3 cache detected but igno=
red");
+ VG_(message)(Vg_DebugMsg,
+ "warning: L3 cache detected but ignored");
break;
=20
/* These are sectored, whatever that means */
@@ -128,7 +140,14 @@
case 0x43: *L2c =3D (cache_t) { 512, 4, 32 }; L2_found =3D True; =
break;
case 0x44: *L2c =3D (cache_t) { 1024, 4, 32 }; L2_found =3D True; =
break;
case 0x45: *L2c =3D (cache_t) { 2048, 4, 32 }; L2_found =3D True; =
break;
- case 0x49: *L2c =3D (cache_t) { 4096,16, 64 }; L2_found =3D True; =
break;
+ case 0x49:
+ if ((family =3D=3D 15) && (model =3D=3D 6))
+ /* On Xeon MP (family F, model 6), this is for L3 */
+ VG_(message)(Vg_DebugMsg,=20
+ "warning: L3 cache detected but ignored\n");
+ else
+ *L2c =3D (cache_t) { 4096, 16, 64 }; L2_found =3D True;
+ break;
=20
/* These are sectored, whatever that means */
case 0x60: *D1c =3D (cache_t) { 16, 8, 64 }; break; /* secto=
red */
|
|
From: <js...@ac...> - 2006-11-23 05:09:49
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-11-23 04:30:01 GMT 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 == 249 tests, 8 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2006-11-23 03:47:18
|
Nightly build on dunsmere ( athlon, Fedora Core 6 ) started at 2006-11-23 03:30: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 == 251 tests, 7 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/xml1 (stderr) none/tests/blockfault (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2006-11-23 03:30:28
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-11-23 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 == 214 tests, 12 stderr failures, 7 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/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (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/jm-int (stdout) 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-11-23 01:16:50
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2006-11-23 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 == 220 tests, 14 stderr failures, 4 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) 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-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) none/tests/blockfault (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-int (stdout) none/tests/ppc64/jm-int (stdout) |
|
From: <sv...@va...> - 2006-11-23 00:32:52
|
Author: njn
Date: 2006-11-23 00:32:46 +0000 (Thu, 23 Nov 2006)
New Revision: 303
Log:
fix typo
Modified:
trunk/gallery/users.html
Modified: trunk/gallery/users.html
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/gallery/users.html 2006-10-30 21:33:57 UTC (rev 302)
+++ trunk/gallery/users.html 2006-11-23 00:32:46 UTC (rev 303)
@@ -241,7 +241,7 @@
a multiformat geospatial raster/vector translator library.</li>
=20
<li><a href=3D"http://www.r-project.org/">R:</a>
- an free software environment for statistical computing and
+ a free software environment for statistical computing and
graphics.</li>
=20
<li><a href=3D"http://www.usf.uos.de/~breiter/tools/statist/index.en.ht=
ml">statist:</a>
|