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
(17) |
2
(8) |
3
(23) |
4
(16) |
5
(13) |
6
(13) |
|
7
|
8
|
9
|
10
(2) |
11
(4) |
12
(2) |
13
(14) |
|
14
(13) |
15
(7) |
16
(13) |
17
(20) |
18
(15) |
19
(15) |
20
(13) |
|
21
(15) |
22
(13) |
23
(13) |
24
(2) |
25
(5) |
26
(12) |
27
|
|
28
(3) |
29
(13) |
30
(13) |
31
(14) |
|
|
|
|
From: Randy M. <rwm...@gm...> - 2013-07-10 14:22:45
|
Anmol, Any news on getting over the legal hurdles for releasing support for the e500v2 SPE architecture? Do you expect it to be weeks or months? :) // Randy On Wed, Jun 19, 2013 at 1:28 PM, Paralkar Anmol-B07584 <B0...@fr... > wrote: > Hello Julian, > > I have created: > > https://bugs.kde.org/show_bug.cgi?id=321396 > > PS: I do not know how to make the bug 'Assigned To' myself; kindly help > with the same. > > Please note that the patches have to clear an internal legal review > process at Freescale > before they can be posted externally. (Meanwhile, the port is available > via our upcoming SDK-1.4 release). > > Kindly advise on any copyright assignment/legal paperwork if needed, so > that we can work on it as well. > > A brief overview of the work is: > - All of the SPE instructions (about 220) are supported: > - FP, Fractional arithmetic instructions are "implemented" as-is via > dirty-helpers. > - All other instructions (integer arithmetic, load-store, logical, ...) > by generating classic Power 32 via expressing in VEX IR. > - There is at least one unit-test per instruction, typically tested > against a sequence of randomly generated > input data (recorded in the test's source code) and creating the > test's baseline by running standalone on > linux and then verifying that we obtain the same results when run > under Valgrind. > - Typical UNIX Utilities like: wc(1), grep(1), ls(1), head(1), gcc(1), > ... work fine on it, used typically. > - TODO's: > - Support for e500v2 in Valgrind's internal gdbserver is yet to be > added. > - ptrace(2), prlimit(2), (and perhaps a lot of other syscalls) yet > unsupported. > - Need to warn on misaligned SPE load-stores (I suppose the e500v2 > linux kernel handles these internally, so we get > a difference in behavior). > > I am sure we'll need to split the patches/rework them some before they > become acceptable for submission and I look forward to > working with the community. > > Thank you very much. > > Regards, > Anmol. > > > -----Original Message----- > > From: Julian Seward [mailto:js...@ac...] > > Sent: Monday, June 10, 2013 7:10 AM > > To: Paralkar Anmol-B07584 > > Cc: val...@li... > > Subject: Re: [Valgrind-developers] Freescale Support for e500v2 SPE in > > Valgrind. > > > > On 05/31/2013 06:50 PM, Paralkar Anmol-B07584 wrote: > > > Hello, > > > > > > Freescale recently added support for the e500v2 SPE architecture based > > off of Valgrind-3.8.1; > > > this will be available in the upcoming SDK-1.4 release and is intended > > to be contributed back > > > to the public-domain mainline Valgrind sources. > > > > Is there a bug in the bug tracker containing the patches, for > > review/testing > > etc? > > > > J > > > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > -- ../Randy/.. |
|
From: Julian S. <js...@ac...> - 2013-07-10 11:41:37
|
Hi s390ers and mipsers, I've been working on a comprehensive fix for https://bugs.kde.org/show_bug.cgi?id=294285 (deal properly with partially-valid 128- and 256-bit vector loads). The core of the problem is that the calls to dirty helper functions that Memcheck generates need to be able to return 16-byte values, and probably in the future 32 byte values. To do this I added the ability of helper functions to return a V128 or V256 by reference. The helper function can declare a V128*/V256* parameter, which it is assumed to put the result in. At the IR level the position of the out parameter is marked by a special value in the argument list (IRExprP__VECRET), but apart from that there's no change at the IR level. The back ends have to be modified to allocate space on the stack when they see such a value, pass the address to the callee, and read the value back out after the call. Passing of the baseblock pointer is now done similarly (IRExprP__BBPTR) and IRDirty.needsBBP is gone. This scheme is probably lower performance than using ABI-specific struct-return conventions, since it goes via memory, but it's simpler and avoids exposure to potential struct-return bugs in gcc -- since it requires no cooperation at all from gcc. Also, in the big picture, this allows replacing two calls to MC_(helperc_LOADV64) with a single call to MC_(helperc_LOADV128) so that should more than compensate for passing the value through memory. Anyway: I have modified the amd64, x86 and ARM back ends to deal with this, and I will do the ppc32 and ppc64 back ends later this week. I could probably do the mips32/64 cases if I could find a working gcc-compile-farm MIPS machine, which I can't. But I can't do the s390 back end. So .. can I enlist your help with this? Because (AFAIK) neither the s390 nor mips back ends deal with vectors, this should be pretty straightforward. It is essentially a change to how doHelperCall in host_xxx_isel.c is called. No change in the generated code. Thanks, J |