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
(7) |
2
(7) |
3
(11) |
4
(3) |
5
(6) |
|
6
(14) |
7
(25) |
8
(14) |
9
(21) |
10
(16) |
11
(3) |
12
(12) |
|
13
|
14
(5) |
15
(11) |
16
(4) |
17
(18) |
18
(15) |
19
|
|
20
(1) |
21
(14) |
22
(7) |
23
(14) |
24
(9) |
25
(14) |
26
(5) |
|
27
(12) |
28
(1) |
29
(5) |
30
|
|
|
|
|
From: Christian B. <bor...@de...> - 2011-11-05 22:56:39
|
>> - binary integer significand field encodes the significand as a large binary integer between 0 and 10p−1. >> vs. >> - densely packed decimal significand field encodes decimal digits more directly. >> but I think this should not matter for IR at all. > > It would matter. At least for VEX purists. Think about translating > across architectures, e.g. s390x dfp to intel. I'm not sure whether > we've given up on cross-translating nowadays but VEX was certainly > originally designed to support it. And that implies capturing the > semantics correctly. That why there are some helpers with inline assemblies? ;-) All joking aside, isnt that also true for binary floating point? 754 mandates the format, but IIRC the in memory representation can differ according to the endianess. |
|
From: Philippe W. <phi...@sk...> - 2011-11-05 22:45:30
|
>> Author: sewardj >> Date: 2011-10-27 11:01:17 +0100 (Thu, 27 Oct 2011) >> New Revision: 12239 >> >> Log: >> Some small doc updating for 3.7.0. > ... >> +<para>You can specify the temporary directory to use either via >> +the <computeroutput>--with-tmpdir=</computeroutput> configure time >> +flag, or by setting environment variable TMPDIR when running Valgrind >> +(on the device, not the Android device). > I do not understand the difference between the device' and 'the Android device'. > Isn't it rather something like: > ' (on the Android device, not on the Android NDK development host).' ? > > Note also that the location for FIFO files can be specifically chosen > with the Valgrind command line option --vgdb-prefix. Unless missed, I have not seen the small typo above fixed (but for sure not a blocking bug for 3.7.0 :). Philippe |
|
From: Florian K. <br...@ac...> - 2011-11-05 14:30:13
|
On 11/04/2011 04:46 PM, Christian Borntraeger wrote: > > Agreed, emulating DFP with IR is definitely the wrong way. > Definitely. >> Next, I asked Carl to look at the feasibility of using the Iex_CCall to a >> helper. This looks promising, but is non-standard and not as straightforward as >> implementing via an instruction-specific Iop. > > Yes, this would work but this is also slow and non-standard. > I would not be too worried about speed. Apps using DFP ops will be rare. But it would definitely be a deviation from the current modelling approach. > I think that adding Iops is the right way to do. > [...] > > Julian, please be aware that Intel is also planning to provide decimal > floating point in the future. They will use a different representation: > - binary integer significand field encodes the significand as a large binary integer between 0 and 10p−1. > vs. > - densely packed decimal significand field encodes decimal digits more directly. > but I think this should not matter for IR at all. It would matter. At least for VEX purists. Think about translating across architectures, e.g. s390x dfp to intel. I'm not sure whether we've given up on cross-translating nowadays but VEX was certainly originally designed to support it. And that implies capturing the semantics correctly. Florian |
|
From: Christian B. <bor...@de...> - 2011-11-05 12:43:18
|
On 05/11/11 02:54, John Reiser wrote:
> On 11/04/2011 01:46 PM, Christian Borntraeger wrote:
> [snip]
>> Given the novelty of decimal floating point libraries a tool like valgrind would
>> be really helpful.
>
> What level of support do you imagine? Memcheck supports binary floating point
> coarsely: if any bit of any input to a floating-point operation is Undefined,
> then all the bits of the output are Undefined.
>
I think it should be identical to binary floating point,e.g. for DFP 64bit Multiply
we do the same as for BFP 64bit Multiply
cborntra@br96egxr:/space/valgrind$ svn diff
Index: memcheck/mc_translate.c
===================================================================
--- memcheck/mc_translate.c (revision 12031)
+++ memcheck/mc_translate.c (working copy)
@@ -2259,6 +2259,7 @@
case Iop_SubF64:
case Iop_SubF64r32:
case Iop_MulF64:
+ case Iop_MulD64:
case Iop_MulF64r32:
case Iop_DivF64:
case Iop_DivF64r32:
cborntra@br96egxr:/space/valgrind$ svn diff VEX/
Index: VEX/priv/ir_defs.c
===================================================================
--- VEX/priv/ir_defs.c (revision 2201)
+++ VEX/priv/ir_defs.c (working copy)
@@ -260,6 +260,7 @@
case Iop_AddF64: vex_printf("AddF64"); return;
case Iop_SubF64: vex_printf("SubF64"); return;
case Iop_MulF64: vex_printf("MulF64"); return;
+ case Iop_MulD64: vex_printf("MulD64"); return;
case Iop_DivF64: vex_printf("DivF64"); return;
case Iop_AddF64r32: vex_printf("AddF64r32"); return;
case Iop_SubF64r32: vex_printf("SubF64r32"); return;
@@ -2235,6 +2236,7 @@
case Iop_AddF64: case Iop_SubF64:
case Iop_MulF64: case Iop_DivF64:
+ case Iop_MulD64:
case Iop_AddF64r32: case Iop_SubF64r32:
case Iop_MulF64r32: case Iop_DivF64r32:
TERNARY(ity_RMode,Ity_F64,Ity_F64, Ity_F64);
Index: VEX/pub/libvex_ir.h
===================================================================
--- VEX/pub/libvex_ir.h (revision 2201)
+++ VEX/pub/libvex_ir.h (working copy)
@@ -1279,7 +1279,16 @@
/* Vector Reciprocal Estimate and Vector Reciprocal Square Root Estimate
See floating-point equiwalents for details. */
- Iop_Recip32x4, Iop_Rsqrte32x4
+ Iop_Recip32x4, Iop_Rsqrte32x4,
+
+ /* ------ Decimal Floating Point IEEE 754-2008 ------ */
+
+ /* Binary operations, with rounding. */
+ /* :: IRRoundingMode(I32) x F64 x F64 -> F64 */
+ Iop_AddD64, Iop_SubD64, Iop_MulD64, Iop_DivD64
+ /* tbd */
+
+
}
IROp;
|
|
From: <sv...@va...> - 2011-11-05 11:27:20
|
Author: sewardj Date: 2011-11-05 11:22:35 +0000 (Sat, 05 Nov 2011) New Revision: 12258 Log: --> 3.7.0 final. Modified: branches/VALGRIND_3_7_BRANCH/NEWS branches/VALGRIND_3_7_BRANCH/configure.in Modified: branches/VALGRIND_3_7_BRANCH/NEWS =================================================================== --- branches/VALGRIND_3_7_BRANCH/NEWS 2011-11-03 02:10:02 UTC (rev 12257) +++ branches/VALGRIND_3_7_BRANCH/NEWS 2011-11-05 11:22:35 UTC (rev 12258) @@ -1,6 +1,6 @@ -Release 3.7.0 (XX November 2011) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Release 3.7.0 (5 November 2011) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.7.0 is a feature release with many significant improvements and the usual collection of bug fixes. @@ -297,7 +297,8 @@ n-i-bz improved checking for VALGRIND_CHECK_MEM_IS_DEFINED (3.7.0-TEST1: 27 October 2011, vex r2228, valgrind r12245) -(3.7.0: XX November 2011, vex rXXXX, valgrind rXXXXX) +(3.7.0.RC1: 1 November 2011, vex r2231, valgrind r12257) +(3.7.0: 5 November 2011, vex r2231, valgrind r12258) Modified: branches/VALGRIND_3_7_BRANCH/configure.in =================================================================== --- branches/VALGRIND_3_7_BRANCH/configure.in 2011-11-03 02:10:02 UTC (rev 12257) +++ branches/VALGRIND_3_7_BRANCH/configure.in 2011-11-05 11:22:35 UTC (rev 12258) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT([Valgrind],[3.7.0-TEST1],[val...@li...]) +AC_INIT([Valgrind],[3.7.0],[val...@li...]) AC_CONFIG_SRCDIR(coregrind/m_main.c) AC_CONFIG_HEADERS([config.h]) AM_INIT_AUTOMAKE([foreign]) |
|
From: John R. <jr...@bi...> - 2011-11-05 01:54:24
|
On 11/04/2011 01:46 PM, Christian Borntraeger wrote: [snip] > Given the novelty of decimal floating point libraries a tool like valgrind would > be really helpful. What level of support do you imagine? Memcheck supports binary floating point coarsely: if any bit of any input to a floating-point operation is Undefined, then all the bits of the output are Undefined. -- |