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
(1) |
|
4
(4) |
5
(5) |
6
(6) |
7
(1) |
8
(1) |
9
(3) |
10
(1) |
|
11
(6) |
12
(1) |
13
|
14
|
15
(1) |
16
(5) |
17
|
|
18
|
19
|
20
(3) |
21
(5) |
22
(1) |
23
(5) |
24
|
|
25
|
26
|
27
|
28
|
29
(3) |
30
|
31
|
|
From: <pa...@fr...> - 2016-12-21 20:29:40
|
----- Original Message ----- > On 12/21/2016 12:57 AM, Ivo Raisr wrote: > > > Are there any objections to the changes for this bug: > > https://bugs.kde.org/show_bug.cgi?id=373938 > > > > The gist of my changes is really just: > > - Bool matchIRExpr ( MatchInfo* mi, IRExpr* p, IRExpr* e ); > > + Bool matchIRExpr ( MatchInfo* mi, const IRExpr* p, const IRExpr* > > e ); > > I applaud the use of 'const' as often as possible. > It increases understanding and reduces debugging and maintenance > costs > because it reduces the places where values can change. > It also tells the compiler where aggressive optimization is possible. Unfortunately, mainly due to pointers/references and aliasing, this isn't as often as one might hope. For instance see http://www.gotw.ca/gotw/081.htm > I believe that 'const' should appear as far to the right as possible: > > IRExpr const *p > > This makes declarations easier to read. Declarations are read > from the inside to the outside; this means right-to-left > (except for function names and order of parameters.) > In the example, what is 'p'? Another link for reading declarations : http://cdecl.org It's somewhat tongue in cheek, and it doesn't support much if any C++. > spoken or read: p is a pointer to a const IRExpr > transliterated: p * const IRExpr > proper syntax: IRExpr const *p > > This placement of 'const' is especially natural in C++, > where the spoken "by const-ref" becomes the syntax "const&". Personally I don't mind either, as long as it's consistent. A+ Paul |
|
From: <sv...@va...> - 2016-12-21 17:45:36
|
Author: petarj
Date: Wed Dec 21 17:45:28 2016
New Revision: 16190
Log:
mips: fix "cast-equal" warnings in coredump-elf.c
Remove the following warnings from the build:
m_coredump/coredump-elf.c:521:31: warning: cast discards 'const'
qualifier from pointer target type [-Wcast-qual]
Related BZ#370028
Patch by Aleksandar Rikalo.
Modified:
trunk/coregrind/m_coredump/coredump-elf.c
Modified: trunk/coregrind/m_coredump/coredump-elf.c
==============================================================================
--- trunk/coregrind/m_coredump/coredump-elf.c (original)
+++ trunk/coregrind/m_coredump/coredump-elf.c Wed Dec 21 17:45:28 2016
@@ -510,15 +510,8 @@
DO(0); DO(1); DO(2); DO(3); DO(4); DO(5); DO(6); DO(7);
DO(8); DO(9); DO(10); DO(11); DO(12); DO(13); DO(14); DO(15);
# undef DO
-#elif defined(VGP_mips32_linux)
-# define DO(n) (*fpu)[n] = *(double*)(&arch->vex.guest_f##n)
- DO(0); DO(1); DO(2); DO(3); DO(4); DO(5); DO(6); DO(7);
- DO(8); DO(9); DO(10); DO(11); DO(12); DO(13); DO(14); DO(15);
- DO(16); DO(17); DO(18); DO(19); DO(20); DO(21); DO(22); DO(23);
- DO(24); DO(25); DO(26); DO(27); DO(28); DO(29); DO(30); DO(31);
-# undef DO
#elif defined(VGP_mips32_linux) || defined(VGP_mips64_linux)
-# define DO(n) (*fpu)[n] = *(double*)(&arch->vex.guest_f##n)
+# define DO(n) (*fpu)[n] = *(const double*)(&arch->vex.guest_f##n)
DO(0); DO(1); DO(2); DO(3); DO(4); DO(5); DO(6); DO(7);
DO(8); DO(9); DO(10); DO(11); DO(12); DO(13); DO(14); DO(15);
DO(16); DO(17); DO(18); DO(19); DO(20); DO(21); DO(22); DO(23);
|
|
From: John R. <jr...@bi...> - 2016-12-21 16:08:41
|
On 12/21/2016 12:57 AM, Ivo Raisr wrote: > Are there any objections to the changes for this bug: > https://bugs.kde.org/show_bug.cgi?id=373938 > > The gist of my changes is really just: > - Bool matchIRExpr ( MatchInfo* mi, IRExpr* p, IRExpr* e ); > + Bool matchIRExpr ( MatchInfo* mi, const IRExpr* p, const IRExpr* e ); I applaud the use of 'const' as often as possible. It increases understanding and reduces debugging and maintenance costs because it reduces the places where values can change. It also tells the compiler where aggressive optimization is possible. I believe that 'const' should appear as far to the right as possible: IRExpr const *p This makes declarations easier to read. Declarations are read from the inside to the outside; this means right-to-left (except for function names and order of parameters.) In the example, what is 'p'? spoken or read: p is a pointer to a const IRExpr transliterated: p * const IRExpr proper syntax: IRExpr const *p This placement of 'const' is especially natural in C++, where the spoken "by const-ref" becomes the syntax "const&". |
|
From: Ivo R. <iv...@iv...> - 2016-12-21 08:57:49
|
Hi developers, Are there any objections to the changes for this bug: https://bugs.kde.org/show_bug.cgi?id=373938 The gist of my changes is really just: - Bool matchIRExpr ( MatchInfo* mi, IRExpr* p, IRExpr* e ); + Bool matchIRExpr ( MatchInfo* mi, const IRExpr* p, const IRExpr* e ); However this resulted in some more 'const' modifiers thrown into various VEX/priv/host_*_isel.c files. Nothing more. I. |
|
From: <pa...@fr...> - 2016-12-21 08:03:51
|
----- Original Message -----
> > Does Valgrind have any macros to distinguish all 32 and 64bit
> > platforms?
> >
> > I'd like to be able to distinguish between the versions of
> > std::size_t on the two types of platforms.
>
> Use the C/C++ language itself, such as:
>
> if (8 == sizeof(size_t)) { // 64-bit (C)
>
> if (8 == sizeof(std::size_t)) { // 64-bit (C++)
OK, thanks. That's probably the most portable as well.
A+
Paul
|