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
(4) |
6
(3) |
7
(3) |
8
(2) |
|
9
(1) |
10
(1) |
11
(2) |
12
(2) |
13
(3) |
14
(7) |
15
(2) |
|
16
|
17
|
18
(1) |
19
|
20
(4) |
21
(1) |
22
(1) |
|
23
|
24
|
25
(2) |
26
(1) |
27
(2) |
28
(2) |
29
(1) |
|
From: Nicholas N. <n.n...@gm...> - 2020-02-14 19:34:46
|
Hi, I have a plan to flip a couple of option defaults for cg_annotate and callgrind_annotate. - Change `--auto=no` to `--auto=yes`. This controls whether source code annotation occurs automatically. It was first implemented way back in 2001 or 2002 and I don't think I have ever run either tool without using `--auto=yes`. - Change `--show-percs=no` to `--show-percs=yes`. I added this option in 3.15 and have never not used it since. It makes the output much nicer to read. In short, I don't like programs with `--make-it-actually-work` options, and I consider both of these to be such options. Let me know if you object, otherwise I will land the changes at the end of the coming week. I will mention them in the NEWS file. Nick On Wed, 5 Feb 2020 at 19:40, Julian Seward <js...@ac...> wrote: > Greetings. > > In the Developer Toolroom at FOSDEM20 last Sunday, there was a bit of > discussion regarding the release date for 3.16.0. The following was > agreed: > > * freeze for large changes on Monday 2 March 2020. > > * final release on Monday 16 March 2020. > > This gives us just under four weeks to land any large changes for 3.16, > followed by a two week stabilisation period before the release. > > My list of changes still to do for 3.16 are: > > * make the new &&-idiom-recognition stuff work also on s390 and MIPS. This > was discussed with both the s390 and MIPS folks on Sunday. If it is not > fixable in the timescale, it's not a disaster since that functionality > can > remain disabled on those targets, as it is now. But if possible it > would be > nice to have it fixed. > > * 64-bit time-related syscalls on 32-bit Linux targets are now failing (esp > for Fedora Rawhide). Mark and/or me can look at this; other volunteers > welcome. > > * Continue testing with gcc 10 (and maybe glibc-the-latest?); make sure it > works. > > * [me] I'd like to land 253657 (improvements to PDB reading) if possible. > > * I would like to remove the exp-sgcheck tool. It hasn't been usable for > years (if ever); it doesn't work at all on non-x86/amd64 targets, and is > generally pointless to keep around. Are there any objections to > removing > it? > > * I'll make another pass through the open bugs within the next week, but > I'm > not aware of any critical bugs right now. > > If this schedule is a problem for anyone, please let us know immediately. > Also, of course, if there are other changes that should go in 3.16, speak > up > now. > > J > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Carl L. <ce...@us...> - 2020-02-14 16:59:44
|
Mark:
On Fri, 2020-02-14 at 17:04 +0100, Mark Wielaard wrote:
> On Fri, 2020-02-14 at 07:58 -0800, Carl Love wrote:
> > > On ppc64[be] I do see an issue with the vbit-test:
> >
> > I looked at the fix mentioned by Aleksandar. It looks like it is
> > architecture independent. I think we have a BE PPC64 machine
> > around.
> > I will see if I can reproduce the issue and then try the fix in KDE
> > #417238.
>
> I just tried that patch on the ppc64[be] machine and it does indeed
> resolve the vbit-test issues.
Ditto, I tried on a Power 8 machine running Red Hat 7.6 (Maipo) in BE
mode. The fix by Aleksandar fixes the Vbit test errors. I will add a
note to that bugzilla to that effect.
Carl Love
|
|
From: Mark W. <ma...@kl...> - 2020-02-14 16:04:31
|
On Fri, 2020-02-14 at 07:58 -0800, Carl Love wrote: > > On ppc64[be] I do see an issue with the vbit-test: > > I looked at the fix mentioned by Aleksandar. It looks like it is > architecture independent. I think we have a BE PPC64 machine > around. > I will see if I can reproduce the issue and then try the fix in KDE > #417238. I just tried that patch on the ppc64[be] machine and it does indeed resolve the vbit-test issues. Cheers, Mark |
|
From: Carl L. <ce...@us...> - 2020-02-14 15:59:08
|
Mark:
On Fri, 2020-02-14 at 14:25 +0100, Mark Wielaard wrote:
> For ppc64 and ppc64le I tested both patches and they seem to work
> nicely.
>
> Fedora release 30 (Thirty)
> Linux 5.2.9-200.fc30.ppc64le #1 SMP Fri Aug 16 21:03:00 UTC 2019
> GNU C Library (GNU libc) stable release version 2.29.
> g++ 9.1.1 and binutils 2.31.1
>
> Fedora release 28 (Twenty Eight)
> Linux 5.0.16-100.fc28.ppc64 #1 SMP Tue May 14 17:55:15 UTC 2019
> GNU C Library (GNU libc) stable release version 2.27.
> g++ 8.3.1 and binutils 2.29.1
>
> I have also backported the first patch to fedora (since that already
> had the original patch by Eugene backported) and it seems to resolve
> all issues (the second patch isn't needed because grail hasn't been
> backported).
Thanks for the testing.
>
> On ppc64[be] I do see an issue with the vbit-test:
I looked at the fix mentioned by Aleksandar. It looks like it is
architecture independent. I think we have a BE PPC64 machine around.
I will see if I can reproduce the issue and then try the fix in KDE
#417238.
Carl Love
|
|
From: John R. <jr...@bi...> - 2020-02-14 14:54:21
|
On 2/14/20 13:25 UTC, Mark Wielaard wrote:
> On ppc64[be] I do see an issue with the vbit-test:
The test itself is incorrect. First of all, the expected value is known but not shown.
Second, for a bit-wise OR operation, if either input has a valid '1' bit in some bit position,
then the result also has a valid '1' bit in that bit position. An input bit that is a valid '1',
makes the other input bit in that bit position into a "don't care" bit.
[A similar rule applies to AND operation with a valid '0' bit.]
Corrected lines are shown below the incorrect ones:
>
> *** Incorrect result for operator Iop_Or1
> opnd 0: vbits = 00000001 value = 00
> opnd 1: vbits = 00000000 value = 01
> result: vbits = 00000001 value = 00
> expect: vbits = 00000000
expect: vbits = 00000000 value = 01
> *** Incorrect result for operator Iop_Or1
> opnd 0: vbits = 00000000 value = 01
> opnd 1: vbits = 00000001 value = 01
> result: vbits = 00000001 value = 00
> expect: vbits = 00000000
expect: vbits = 00000001 value = 01
> *** Incorrect result for operator Iop_Or1
> opnd 0: vbits = 00000001 value = 01
> opnd 1: vbits = 00000000 value = 00
> result: vbits = 00000001 value = 00
> expect: vbits = 00000000 expect: vbits = 00000001 value = 01
> *** Incorrect result for operator Iop_Or1
> opnd 0: vbits = 00000000 value = 00
> opnd 1: vbits = 00000001 value = 00
> result: vbits = 00000001 value = 00
> expect: vbits = 00000000
expect: vbits = 00000000 value = 00
|
|
From: Aleksandar R. <ale...@rt...> - 2020-02-14 14:23:49
|
Hi, The vbit-test has that issue on all BE platforms. There is a fix attached on KDE #417238, it works for mips64 BE. Aleksandar On 14.2.20. 14:25, Mark Wielaard wrote: > > On ppc64[be] I do see an issue with the vbit-test: > > *** Incorrect result for operator Iop_Or1 > opnd 0: vbits = 00000001 value = 00 > opnd 1: vbits = 00000000 value = 01 > result: vbits = 00000001 value = 00 > expect: vbits = 00000000 > *** Incorrect result for operator Iop_Or1 > opnd 0: vbits = 00000000 value = 01 > opnd 1: vbits = 00000001 value = 01 > result: vbits = 00000001 value = 00 > expect: vbits = 00000000 > *** Incorrect result for operator Iop_Or1 > opnd 0: vbits = 00000001 value = 01 > opnd 1: vbits = 00000000 value = 00 > result: vbits = 00000001 value = 00 > expect: vbits = 00000000 > *** Incorrect result for operator Iop_Or1 > opnd 0: vbits = 00000000 value = 00 > opnd 1: vbits = 00000001 value = 00 > result: vbits = 00000001 value = 00 > expect: vbits = 00000000 > > > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Mark W. <ma...@kl...> - 2020-02-14 13:25:21
|
Hi,
On Thu, 2020-02-13 at 14:22 -0800, Carl Love wrote:
> The fix is actually in a PPC64 specific file. The error occurs
> because
> PPC64 checks that the structure is aligned properly. Not sure if other
> architectures check the alignment or not. If they do, then they could
> see the same issue. The structure is defined on a per architecture
> basis which means other architectures would need to implement a similar
> fix in their architecture specific file.
>
> The patch talked about 64-bit architectures specifically amd64 arm64.
> Hence I was thinking architecture independent as I was writing the
> email and forgot that the actual fix was in a ppc64 specific file. I
> guess I forgot that detail while working on the second patch.
I don't believe any other architecture has a check that the structure
is aligned correctly. So it isn't causing immediate problems on other
architectures. I cannot tell whether they should or shouldn't have such
a check though.
For ppc64 and ppc64le I tested both patches and they seem to work
nicely.
Fedora release 30 (Thirty)
Linux 5.2.9-200.fc30.ppc64le #1 SMP Fri Aug 16 21:03:00 UTC 2019
GNU C Library (GNU libc) stable release version 2.29.
g++ 9.1.1 and binutils 2.31.1
Fedora release 28 (Twenty Eight)
Linux 5.0.16-100.fc28.ppc64 #1 SMP Tue May 14 17:55:15 UTC 2019
GNU C Library (GNU libc) stable release version 2.27.
g++ 8.3.1 and binutils 2.29.1
I have also backported the first patch to fedora (since that already
had the original patch by Eugene backported) and it seems to resolve
all issues (the second patch isn't needed because grail hasn't been
backported).
On ppc64[be] I do see an issue with the vbit-test:
*** Incorrect result for operator Iop_Or1
opnd 0: vbits = 00000001 value = 00
opnd 1: vbits = 00000000 value = 01
result: vbits = 00000001 value = 00
expect: vbits = 00000000
*** Incorrect result for operator Iop_Or1
opnd 0: vbits = 00000000 value = 01
opnd 1: vbits = 00000001 value = 01
result: vbits = 00000001 value = 00
expect: vbits = 00000000
*** Incorrect result for operator Iop_Or1
opnd 0: vbits = 00000001 value = 01
opnd 1: vbits = 00000000 value = 00
result: vbits = 00000001 value = 00
expect: vbits = 00000000
*** Incorrect result for operator Iop_Or1
opnd 0: vbits = 00000000 value = 00
opnd 1: vbits = 00000001 value = 00
result: vbits = 00000001 value = 00
expect: vbits = 00000000
|