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
|
|
2
|
3
|
4
|
5
(3) |
6
(2) |
7
|
8
|
|
9
|
10
|
11
|
12
|
13
|
14
|
15
(1) |
|
16
(4) |
17
(1) |
18
|
19
|
20
|
21
(1) |
22
(1) |
|
23
|
24
|
25
|
26
|
27
(3) |
28
(1) |
29
|
|
30
|
31
(6) |
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2017-07-06 12:52:11
|
Hi Tanya, Sorry for the slow reply. I was OOo last week. > We have implemented a number of AVX-512 instructions in Valgrind core. > NAS IS benchmark, compiled with AVX-512, runs correctly under Nulgrind. > Tests for the implemented AVX-512 instructions (similar to the tests in > ./none/tests/amd64/avx2-1.c) also work correctly. Good. > 1. What has higher priority, Memcheck correctness or full instruction set coverage? Instruction set coverage. Getting Memcheck to handle new IRs is much easier than adding new insn support. > 2. When should we start submitting patches: when everything is added and > tested on more benchmarks, or earlier, in order to review a work-in- > progress? Earlier is better. Even if they don't get landed immediately, they can be looked at by others. In particular I'd like to see what new IROps you had to add. Do you have a bug report (bugs.kde.org) tracking this, to which you can attach the patches? That is the usual way of doing reviews. J |
|
From: Mark W. <ma...@kl...> - 2017-07-06 07:26:41
|
On Thu, 2017-07-06 at 08:18 +0200, Florian Weimer wrote: > On 07/06/2017 06:14 AM, Siddhesh Poyarekar wrote: > > On Thursday 06 July 2017 12:34 AM, Florian Weimer wrote: > >> Why do you expect valgrind to be able to execute code specific to vendor > >> CPUs? That's not even true for i386 and x86-64 and micro-architecture > >> ISA extensions. > > > > The expectation is that it looks for potential memory access issues in > > these low level functions themselves, but that is probably too much to > > expect. However this: > > > > (c) the glibc SSE-variants can read past the end of the input data > > ranges. This can cause false-positive Memcheck / Helgrind / DRD > > reports. > > > > sounds scary. It's been a while since I've looked at the x86 versions > > of the string functions, do you (or Mark) know what this is referring to > > and why it is safe? > > There is a page boundary check upfront, or this only happens after the > pointer is aligned and the load cannot cross a page boundary. > > > It would be nice to get some more details of this one as well: > > > > (b) some of the normal versions are hyper-optimised, which fools > > Memcheck and cause spurious value warnings. Our versions are > > simpler. > > > > specifically whether it is x86-specific or true for other architectures > > as well > > I'm not sure if this is what (b) is about, but for some instructions or > instruction sequences it is hard to implement proper uninitialized value > tracking, so that valgrind reports a dependency on uninitialized data > which does not in fact exist because the bits are masked away in > practice, but valgrind does not see this due to this problem. Right, the hand-written glibc mem/str assembly routines are sometimes a little too clever. valgrind/memcheck is optimized for code generated by actual compilers. And valgrind has a somewhat stricter definition/view of addressable memory (since it knows exactly how big an allocated buffer is because it intercepts all memory allocation functions). See also the valgrind/memcheck options --partial-loads-ok and --expensive-definedness-checks: http://valgrind.org/docs/manual/mc-manual.html#opt.partial-loads-ok http://valgrind.org/docs/manual/mc-manual.html#opt.expensive-definedness-checks In newer valgrind releases the first defaults to yes, the second to no. Cheers, Mark |