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
(1) |
2
|
|
3
|
4
|
5
(5) |
6
|
7
(3) |
8
|
9
|
|
10
|
11
|
12
(4) |
13
(1) |
14
|
15
|
16
|
|
17
|
18
|
19
|
20
|
21
(3) |
22
|
23
|
|
24
|
25
|
26
|
27
|
28
|
29
|
30
|
|
31
|
|
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2017-12-07 18:10:20
|
tl;dr Unavoidable but small Memcheck slowdowns to reduce false positives. As compilers have become more aggressive over the past few years, Memcheck's false-positive rate for undefined-value-error reports has been creeping up. This has particularly become a problem with GCC 6 and LLVM 4. There are various causes of these false errors. Many of them have to do with the fact that Memcheck does not track definedness exactly through some kinds of integer arithmetic operations. For example, for addition, it assumes worst-case carry propogation, so it believes that any undefined bits in either operand will make all higher-order bits in the result be undefined. There is similar shortcutting in many other places too. These shortcuts all have the property that they are "safe", in the sense that they underestimate the definedness of computations. This means they won't lead to false negatives. But they are now causing false positives. The trunk has for a while had --expensive-definedness-checks=no|yes [no], which, when enabled, gives exactly correct behaviour for integer add, subtract, and equality comparison. I propose to enable this by default. As it stands, this gives a performance hit of up to 30%. At https://bugs.kde.org/show_bug.cgi?id=387664 I have a patch which reduces that performance hit substantially, by using a couple of optimisations described in that bug. It is a shame to lose performance, but I consider that maintaining a very low false positive rate is of higher priority. I believe the actual perf loss for run-of-the-mill integer code will be in the range 1.5% to 3%. As a benchmark, I measured gcc-8 cc1 compiling a 6500 line program (perf/bz2.c) (command line below). Results are --expensive-definedness-checks= setting | | time(s) code bytes produced ratio to orig no [old default] 73.2 (+ 0.0%) 60,529,262 (+ 0.0%) 16.7:1 auto [new default] 74.6 (+ 1.9%) 62,544,067 (+ 3.3%) 17.3:1 yes 82.1 (+11.2%) 72,180,432 (+19.2%) 19.9:1 So for gcc-8 the perf hit is 1.9%. I also measured with the perf/vg_perf framework. The numbers are below. They are varied but on the whole quite a bit worse than 1.9%. I think this is partly the cost of the new instrumentation-time analysis pass (see bug 387664), partly a result of different frequencies of integer add and compare in the different benchmarks, and partly dependent on how effective the abovementioned analysis pass is finding operations for which the expensive and cheap instrumentation schemes give the same result. I regret the loss of performance, but I cannot see any other feasible way to proceed. J gcc test run command: ./vg-in-place --stats=yes \ /home/sewardj/Tools/InstGcc8X/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/cc1 \ -quiet -I . perf/bz2.c -quiet -dumpbase bz2.c -mtune=generic \ -march=x86-64 -auxbase-strip bz2.c -O -o bz2.s perf test results (--reps=10, very quiet machine): -- Running tests in ./perf -------------------------------------------- -- bigcode1 -- bigcode1 trunk :0.07s no: 1.3s (18.7x, -----) me: 2.4s (34.9x, -----) bigcode1 patched :0.07s no: 1.3s (18.7x, 0.0%) me: 2.7s (38.6x,-10.7%) -- bigcode2 -- bigcode2 trunk :0.08s no: 2.8s (34.4x, -----) me: 5.7s (71.1x, -----) bigcode2 patched :0.08s no: 2.8s (34.4x, 0.0%) me: 6.6s (82.8x,-16.3%) -- bz2 -- bz2 trunk :0.52s no: 1.7s ( 3.2x, -----) me: 4.8s ( 9.2x, -----) bz2 patched :0.52s no: 1.7s ( 3.2x, 0.0%) me: 5.2s (10.1x, -9.2%) -- fbench -- fbench trunk :0.16s no: 0.9s ( 5.4x, -----) me: 3.0s (18.6x, -----) fbench patched :0.16s no: 0.9s ( 5.4x, 0.0%) me: 3.0s (18.7x, -0.3%) -- ffbench -- ffbench trunk :0.17s no: 0.9s ( 5.6x, -----) me: 2.7s (16.1x, -----) ffbench patched :0.17s no: 0.9s ( 5.6x, 0.0%) me: 2.9s (16.8x, -4.0%) -- heap -- heap trunk :0.06s no: 0.7s (11.0x, -----) me: 4.0s (66.5x, -----) heap patched :0.06s no: 0.7s (10.8x, 1.5%) me: 4.0s (67.0x, -0.8%) -- heap_pdb4 -- heap_pdb4 trunk :0.07s no: 0.7s (10.3x, -----) me: 6.3s (89.7x, -----) heap_pdb4 patched :0.07s no: 0.7s (10.3x, 0.0%) me: 6.3s (90.3x, -0.6%) -- many-loss-records -- many-loss-records trunk :0.01s no: 0.2s (20.0x, -----) me: 1.0s (97.0x, -----) many-loss-records patched :0.01s no: 0.2s (20.0x, 0.0%) me: 1.0s (98.0x, -1.0%) -- many-xpts -- many-xpts trunk :0.03s no: 0.3s ( 8.7x, -----) me: 1.2s (40.3x, -----) many-xpts patched :0.03s no: 0.3s ( 8.7x, 0.0%) me: 1.2s (41.3x, -2.5%) -- memrw -- memrw trunk :0.04s no: 0.3s ( 8.8x, -----) me: 0.8s (20.5x, -----) memrw patched :0.04s no: 0.4s ( 9.0x, -2.9%) me: 0.9s (23.5x,-14.6%) -- sarp -- sarp trunk :0.02s no: 0.2s (12.0x, -----) me: 1.7s (83.5x, -----) sarp patched :0.02s no: 0.2s (11.5x, 4.2%) me: 1.8s (88.5x, -6.0%) -- tinycc -- tinycc trunk :0.12s no: 1.0s ( 8.3x, -----) me: 7.1s (59.4x, -----) tinycc patched :0.12s no: 1.0s ( 8.3x, 0.0%) me: 7.2s (60.4x, -1.7%) -- Finished tests in ./perf -------------------------------------------- |
|
From: Julian S. <se...@so...> - 2017-12-07 12:33:35
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=0e7c46401bd3a3094459d8ea5231906caaf862a8 commit 0e7c46401bd3a3094459d8ea5231906caaf862a8 Author: Julian Seward <js...@ac...> Date: Thu Dec 7 13:31:38 2017 +0100 Fix this test to work properly with accurate CmpEQ/NE definedness tracking Memcheck reports an error on "if (n == 42)" in this test. Unless, that is, accurate CmpEQ/NE definedness tracking is enabled. If you stare at this long enough it is possible to see that the test "n == 42" isn't actually undefined, because |n| is only ever zero or one, and only its least significant bit is undefined. So the equality comparison against 42 is defined because there are corresponding bits in the two operands that are different and are both defined. This commit fixes that by comparing with 1, which forces the result to really depend on the only undefined bit in |n|. I also added robustification: * return arbitrary values from gcc_cant_inline_me(), so as to avoid gcc simply copying the input to the output or otherwise deleting the conditional branch. * marking gcc_cant_inline_me() as un-inlineable * Putting compiler barriers in the second conditional in main(), so gcc can't simply ignore the result of the call to gcc_cant_inline_me() and then delete the call entirely. Diff: --- memcheck/tests/manuel3.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/memcheck/tests/manuel3.c b/memcheck/tests/manuel3.c index 91030fc..8e60077 100644 --- a/memcheck/tests/manuel3.c +++ b/memcheck/tests/manuel3.c @@ -1,8 +1,8 @@ #include <stdio.h> #include <stdlib.h> - -int gcc_cant_inline_me ( int ); - +int foo, bar; +#define CBAR do { __asm__ __volatile__("":::"cc","memory"); } while (0) +int* gcc_cant_inline_me ( int ); int main () { int *x, y; @@ -11,18 +11,18 @@ int main () y = *x == 173; - if (gcc_cant_inline_me(y)) { } + if (gcc_cant_inline_me(y) == &foo) { CBAR; } else { CBAR; } return 0; } /* must be AFTER main */ -int gcc_cant_inline_me ( int n ) +__attribute__((noinline)) int* gcc_cant_inline_me ( int n ) { - if (n == 42) - return 1; /* forty-two, dudes! */ + if (n == 1) + return &foo; /* foo! */ else - return 0; /* some other number, dudes! */ + return &bar; /* bar! */ } |
|
From: Julian S. <se...@so...> - 2017-12-07 11:26:48
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=8a2acb304db99c0760de32b684e2ec09b7e52bd2 commit 8a2acb304db99c0760de32b684e2ec09b7e52bd2 Author: Julian Seward <js...@ac...> Date: Thu Dec 7 12:24:57 2017 +0100 amd64: add a spec rule for SHRL/SARL then CondS. gcc-8 has been seen to generate such things. Diff: --- VEX/priv/guest_amd64_helpers.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/VEX/priv/guest_amd64_helpers.c b/VEX/priv/guest_amd64_helpers.c index e3bfffa..e3bac96 100644 --- a/VEX/priv/guest_amd64_helpers.c +++ b/VEX/priv/guest_amd64_helpers.c @@ -1744,6 +1744,26 @@ IRExpr* guest_amd64_spechelper ( const HChar* function_name, mkU32(0))); } + if (isU64(cc_op, AMD64G_CC_OP_SHRL) && isU64(cond, AMD64CondS)) { + /* SHRL/SARL, then S --> (ULong)result[31] */ + return binop(Iop_And64, + binop(Iop_Shr64, cc_dep1, mkU8(31)), + mkU64(1)); + } + // The following looks correct to me, but never seems to happen because + // the front end converts jns to js by switching the fallthrough vs + // taken addresses. See jcc_01(). But then why do other conditions + // considered by this function show up in both variants (xx and Nxx) ? + //if (isU64(cc_op, AMD64G_CC_OP_SHRL) && isU64(cond, AMD64CondNS)) { + // /* SHRL/SARL, then NS --> (ULong) ~ result[31] */ + // vassert(0); + // return binop(Iop_Xor64, + // binop(Iop_And64, + // binop(Iop_Shr64, cc_dep1, mkU8(31)), + // mkU64(1)), + // mkU64(1)); + //} + /*---------------- COPY ----------------*/ /* This can happen, as a result of amd64 FP compares: "comisd ... ; jbe" for example. */ |