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
(4) |
2
(1) |
3
|
|
4
|
5
(6) |
6
|
7
(7) |
8
(2) |
9
(1) |
10
(2) |
|
11
(4) |
12
(1) |
13
(4) |
14
(5) |
15
(2) |
16
(5) |
17
(2) |
|
18
(3) |
19
(12) |
20
(10) |
21
(3) |
22
(7) |
23
(4) |
24
(5) |
|
25
(3) |
26
(2) |
27
(1) |
28
|
29
(1) |
30
(1) |
|
|
From: Knapp, R. L <ras...@in...> - 2016-09-20 23:22:58
|
Hello Julian, Thank you for your input on this. I am looking into options to provide remote access to systems which supports AVX-512. The greatest challenge I see to this is that there must be an NDA relationship in place and all of the external users must be approved for remote access. Do you think it might be a reasonable avenue to pursue an NDA relationship with Valgrind? I do not know anything about Valgrind's business structure or who would be the point of contact for an NDA relationship. If this is something you think is reasonable, I will pursue this option. I cannot promise "administrative-hassle-free" because the system(s) are owned and administered by Intel and will have downtimes for maintenance. With this option, once the remote access agreements have been established, Knights Landing access is a possibility, and then Skylake later. Best regards, Rashawn Knapp Software Development Engineer, Intel Corporation -----Original Message----- From: Julian Seward [mailto:js...@ac...] Sent: Wednesday, September 07, 2016 1:24 AM To: Knapp, Rashawn L <ras...@in...>; Petar Jovanovic <mip...@gm...> Cc: val...@li...; val...@li... Subject: Re: [Valgrind-users] [Valgrind-developers] AVX-512 support inquiry Yes, I have seen AVX-512 looming on the horizon for a while. Yes, we should support it. Dealing with AVX/AVX2 was a lot of work, and there is not much AVX-512 available hardware out there, which may explain the relative lack of activity so far. I would be willing to make the infrastructural changes in VEX and Valgrind necessary to provide a framework in which we can incrementally add support for individual instructions. That would be: addition of support for 512 bit registers, changes in the front end instruction decoding framework, and changes in the back end (if any required, possibly none). One problem is the lack of hardware. As I understand it, some but not all Skylake CPUs support AVX-512. Having said that, if you are really looking for a working implementation on Knights Landing then it would be necessary to test any implementation both on Skylake+AVX512 and Knights Landing. A good description of the instruction set is also necessary. Is that publically available? Can you make available, reliable, administrative-hassle-free remote access to a box that supports AVX-512? J > -----Original Message----- > From: Petar Jovanovic [mailto:mip...@gm...] > Sent: Monday, September 05, 2016 11:48 AM > To: Jeff Hammond <jef...@gm...> > Cc: val...@li...; > val...@li...; Mark Wielaard <mj...@re...> > Subject: Re: [Valgrind-developers] [Valgrind-users] AVX-512 support > inquiry > > On Mon, Sep 5, 2016 at 6:31 PM, Jeff Hammond <jef...@gm...> wrote: >> >> It would be really valuable to a number of HPC programmers. Many DOE >> labs use it heavily. I wish I could help implement but I don't have >> the relevant skills. >> > > It may be worth to open a bug at kde and track future discussion there. |
|
From: <sv...@va...> - 2016-09-20 18:59:48
|
Author: sewardj
Date: Tue Sep 20 19:59:41 2016
New Revision: 15973
Log:
Merge from trunk, r15971 (Add a feature check for tests that use -march=armv8-a+crc.)
Modified:
branches/VALGRIND_3_12_BRANCH/ (props changed)
branches/VALGRIND_3_12_BRANCH/configure.ac
branches/VALGRIND_3_12_BRANCH/none/tests/arm64/Makefile.am
branches/VALGRIND_3_12_BRANCH/none/tests/arm64/crc32.vgtest
Modified: branches/VALGRIND_3_12_BRANCH/configure.ac
==============================================================================
--- branches/VALGRIND_3_12_BRANCH/configure.ac (original)
+++ branches/VALGRIND_3_12_BRANCH/configure.ac Tue Sep 20 19:59:41 2016
@@ -2685,6 +2685,29 @@
AM_CONDITIONAL(BUILD_IFUNC_TESTS, test x$ac_have_ifunc_attr = xyes)
+# Does the C compiler support the armv8 crc feature flag
+# Note, this doesn't generate a C-level symbol. It generates a
+# automake-level symbol (BUILD_ARMV8_CRC_TESTS), used in test Makefile.am's
+AC_MSG_CHECKING([if gcc supports the armv8 crc feature flag])
+
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -march=armv8-a+crc -Werror"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+int main()
+{
+ return 0;
+}
+]])], [
+ac_have_armv8_crc_feature=yes
+AC_MSG_RESULT([yes])
+], [
+ac_have_armv8_crc_feature=no
+AC_MSG_RESULT([no])
+])
+CFLAGS="$save_CFLAGS"
+
+AM_CONDITIONAL(BUILD_ARMV8_CRC_TESTS, test x$ac_have_armv8_crc_feature = xyes)
+
# XXX JRS 2010 Oct 13: what is this for? For sure, we don't need this
# when building the tool executables. I think we should get rid of it.
Modified: branches/VALGRIND_3_12_BRANCH/none/tests/arm64/Makefile.am
==============================================================================
--- branches/VALGRIND_3_12_BRANCH/none/tests/arm64/Makefile.am (original)
+++ branches/VALGRIND_3_12_BRANCH/none/tests/arm64/Makefile.am Tue Sep 20 19:59:41 2016
@@ -12,12 +12,15 @@
check_PROGRAMS = \
allexec \
- crc32 \
cvtf_imm \
fp_and_simd \
integer \
memory
+if BUILD_ARMV8_CRC_TESTS
+ check_PROGRAMS += crc32
+endif
+
AM_CFLAGS += @FLAG_M64@
AM_CXXFLAGS += @FLAG_M64@
AM_CCASFLAGS += @FLAG_M64@
Modified: branches/VALGRIND_3_12_BRANCH/none/tests/arm64/crc32.vgtest
==============================================================================
--- branches/VALGRIND_3_12_BRANCH/none/tests/arm64/crc32.vgtest (original)
+++ branches/VALGRIND_3_12_BRANCH/none/tests/arm64/crc32.vgtest Tue Sep 20 19:59:41 2016
@@ -1,2 +1,3 @@
prog: crc32
+prereq: test -x crc32
vgopts: -q
|
|
From: <sv...@va...> - 2016-09-20 18:57:08
|
Author: sewardj
Date: Tue Sep 20 19:57:01 2016
New Revision: 15972
Log:
Merge from trunk, r15970 (fix for bugzilla 361253 [s390x])
Modified:
branches/VALGRIND_3_12_BRANCH/ (props changed)
branches/VALGRIND_3_12_BRANCH/NEWS (contents, props changed)
branches/VALGRIND_3_12_BRANCH/none/tests/s390x/Makefile.am
Modified: branches/VALGRIND_3_12_BRANCH/NEWS
==============================================================================
--- branches/VALGRIND_3_12_BRANCH/NEWS (original)
+++ branches/VALGRIND_3_12_BRANCH/NEWS Tue Sep 20 19:57:01 2016
@@ -169,6 +169,7 @@
368412 False positive result for altivec capability check
368461 mmapunmap test fails on ppc64
369000 AMD64 fma4 instructions unsupported.
+361253 [s390x] ex_clone.c:42: undefined reference to `pthread_create'
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 and amd64
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
Modified: branches/VALGRIND_3_12_BRANCH/none/tests/s390x/Makefile.am
==============================================================================
--- branches/VALGRIND_3_12_BRANCH/none/tests/s390x/Makefile.am (original)
+++ branches/VALGRIND_3_12_BRANCH/none/tests/s390x/Makefile.am Tue Sep 20 19:57:01 2016
@@ -63,4 +63,4 @@
cu24_1_CFLAGS = $(AM_CFLAGS) -DM3=1
fixbr_CFLAGS = $(AM_CFLAGS) @FLAG_MLONG_DOUBLE_128@
fpext_CFLAGS = $(AM_CFLAGS) @FLAG_MLONG_DOUBLE_128@
-ex_clone_LDFLAGS = -lpthread
+ex_clone_LDADD = -lpthread
|
|
From: Rich C. <rc...@wi...> - 2016-09-20 18:15:10
|
On Tue, 20 Sep 2016 11:34:08 +0200 Mark Wielaard <mj...@re...> wrote: > On Sun, 2016-09-18 at 22:18 +0200, Mark Wielaard wrote: > Could people check whether with this new testcase the test no-longer > hangs and whether or not is passes? If it fails could you double check > whether or not it fails always or just sometimes? And if you know why > that would be very helpful to know! > Thanks Mark. The bar_bad testcase is no longer hanging and they are passing. Rich -- Rich Coe rc...@wi... |
|
From: <sv...@va...> - 2016-09-20 17:57:07
|
Author: mjw
Date: Tue Sep 20 18:57:00 2016
New Revision: 15971
Log:
Add a feature check for tests that use -march=armv8-a+crc.
Older gcc versions for arm64 don't support the crc arch feature.
Modified:
trunk/configure.ac
trunk/none/tests/arm64/Makefile.am
trunk/none/tests/arm64/crc32.vgtest
Modified: trunk/configure.ac
==============================================================================
--- trunk/configure.ac (original)
+++ trunk/configure.ac Tue Sep 20 18:57:00 2016
@@ -2685,6 +2685,29 @@
AM_CONDITIONAL(BUILD_IFUNC_TESTS, test x$ac_have_ifunc_attr = xyes)
+# Does the C compiler support the armv8 crc feature flag
+# Note, this doesn't generate a C-level symbol. It generates a
+# automake-level symbol (BUILD_ARMV8_CRC_TESTS), used in test Makefile.am's
+AC_MSG_CHECKING([if gcc supports the armv8 crc feature flag])
+
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -march=armv8-a+crc -Werror"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
+int main()
+{
+ return 0;
+}
+]])], [
+ac_have_armv8_crc_feature=yes
+AC_MSG_RESULT([yes])
+], [
+ac_have_armv8_crc_feature=no
+AC_MSG_RESULT([no])
+])
+CFLAGS="$save_CFLAGS"
+
+AM_CONDITIONAL(BUILD_ARMV8_CRC_TESTS, test x$ac_have_armv8_crc_feature = xyes)
+
# XXX JRS 2010 Oct 13: what is this for? For sure, we don't need this
# when building the tool executables. I think we should get rid of it.
Modified: trunk/none/tests/arm64/Makefile.am
==============================================================================
--- trunk/none/tests/arm64/Makefile.am (original)
+++ trunk/none/tests/arm64/Makefile.am Tue Sep 20 18:57:00 2016
@@ -12,12 +12,15 @@
check_PROGRAMS = \
allexec \
- crc32 \
cvtf_imm \
fp_and_simd \
integer \
memory
+if BUILD_ARMV8_CRC_TESTS
+ check_PROGRAMS += crc32
+endif
+
AM_CFLAGS += @FLAG_M64@
AM_CXXFLAGS += @FLAG_M64@
AM_CCASFLAGS += @FLAG_M64@
Modified: trunk/none/tests/arm64/crc32.vgtest
==============================================================================
--- trunk/none/tests/arm64/crc32.vgtest (original)
+++ trunk/none/tests/arm64/crc32.vgtest Tue Sep 20 18:57:00 2016
@@ -1,2 +1,3 @@
prog: crc32
+prereq: test -x crc32
vgopts: -q
|
|
From: <sv...@va...> - 2016-09-20 12:31:57
|
Author: cborntra
Date: Tue Sep 20 13:31:49 2016
New Revision: 15970
Log:
fix for bugzilla 361253 [s390x] ex_clone.c:42: undefined reference to `pthread_create'
Fix provides by Dann Frazier
Modified:
trunk/NEWS
trunk/none/tests/s390x/Makefile.am
Modified: trunk/NEWS
==============================================================================
--- trunk/NEWS (original)
+++ trunk/NEWS Tue Sep 20 13:31:49 2016
@@ -169,6 +169,7 @@
368412 False positive result for altivec capability check
368461 mmapunmap test fails on ppc64
369000 AMD64 fma4 instructions unsupported.
+361253 [s390x] ex_clone.c:42: undefined reference to `pthread_create'
n-i-bz Fix incorrect (or infinite loop) unwind on RHEL7 x86 and amd64
n-i-bz massif --pages-as-heap=yes does not report peak caused by mmap+munmap
Modified: trunk/none/tests/s390x/Makefile.am
==============================================================================
--- trunk/none/tests/s390x/Makefile.am (original)
+++ trunk/none/tests/s390x/Makefile.am Tue Sep 20 13:31:49 2016
@@ -63,4 +63,4 @@
cu24_1_CFLAGS = $(AM_CFLAGS) -DM3=1
fixbr_CFLAGS = $(AM_CFLAGS) @FLAG_MLONG_DOUBLE_128@
fpext_CFLAGS = $(AM_CFLAGS) @FLAG_MLONG_DOUBLE_128@
-ex_clone_LDFLAGS = -lpthread
+ex_clone_LDADD = -lpthread
|
|
From: Julian S. <js...@ac...> - 2016-09-20 11:24:53
|
On 16/09/16 20:42, Rhys Kidd wrote: >> I am currently unsure about the status of the following ports: >> >> * MacOS X 10.12 > > A patch set that provides the initial bring up on macOS 10.12 is on > Bugzilla: > https://bugs.kde.org/show_bug.cgi?id=365327 Could you land that, sooner rather than later, so as to get any build system changes onto the branch sooner rather than later? It looks like those patches won't have any effect on the existing 10.11 support, correct? > I hope to address the memory mapping problem over the weekend. Thanks. J |
|
From: <sv...@va...> - 2016-09-20 10:51:45
|
Author: sewardj
Date: Tue Sep 20 11:51:37 2016
New Revision: 512
Log:
Update re Solaris port developers. Fixes #362953.
Modified:
trunk/info/developers.html
Modified: trunk/info/developers.html
==============================================================================
--- trunk/info/developers.html (original)
+++ trunk/info/developers.html Tue Sep 20 11:51:37 2016
@@ -94,14 +94,14 @@
<tr valign="top">
<td><b>Petr Pavlu</b><br />
</td>
- <td>Petr is the initial author of Solaris and illumos port on x86 and amd64, wrote core functionality, door handling, added many tests, and maintains the illumos port.</td>
+ <td>Petr is the initial author of the Solaris/illumos port on x86 and amd64, that he and Ivo contributed.</td>
</tr>
<tr valign="top">
<td><b>Ivo Raisr</b><br />
</td>
- <td>Ivo contributed coredump support, wrappers, more tests and maintains the Solaris port.</td>
+ <td>Ivo worked on and maintains the Solaris port.</td>
</tr>
|
|
From: Julian S. <js...@ac...> - 2016-09-20 10:48:25
|
Ivo, Hi. > Patch for the following bug is ready to land, IMO. > I'd like to have another set of eyeballs review the changes before I > integrate it, though: > > 367995 Integration of memcheck with custom memory allocator Done -- comments in bugzilla. J |
|
From: Mark W. <mj...@re...> - 2016-09-20 09:34:17
|
On Sun, 2016-09-18 at 22:18 +0200, Mark Wielaard wrote: > > On my Linux/Ubuntu box these tests hang even when run natively during the > > fourth testcase described as > > "destroy a barrier that has waiting threads". According to POSIX [1]: > > "...The results are undefined if *pthread_barrier_destroy*() is called when > > any thread is blocked on the barrier... " > > which bar_bad precisely does. > > > > Perhaps a timer which would time out this hang would be handy here. > > My apologies for not recognizing this earlier. We carry a patch in Fedora > to work around this test hang. The workaround is attached to this bug > report: https://bugsfiles.kde.org/attachment.cgi?id=96765 > > As you can read in that bug report the workaround isn't ideal because > it might still FAIL the test. If someone could take a look at the bug > and proposed patch to see if it can somehow be changed so that it > makes the test reliably pass with older and newer glibc that would be > very appreciated. I checked in my workaround as valgrind svn r15962 (adding a missing exp file in svn r15966, sorry about that). It adds a sleeping thread that tries to unblock the barrier in case the test hangs (plus new exp files that describe that situation). It does seem to unblock the test, but it adds (more) non-determinism that seems to make the test fail more than before. So I kept the bug report open: https://bugs.kde.org/show_bug.cgi?id=358213 Could people check whether with this new testcase the test no-longer hangs and whether or not is passes? If it fails could you double check whether or not it fails always or just sometimes? And if you know why that would be very helpful to know! Thanks, Mark |