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: Carl L. <ce...@us...> - 2020-02-13 22:22:25
|
Valgrind developers:
Per my discussion with Mark on slack, I should clarify my comment on
this patch.
> On Thu, 2020-02-13 at 13:53 -0800, Carl Love wrote:
> Valgrind developers:
>
> The PPC architecture has a number of "new" regression errors. There
> appear to be two root causes for these issues. Not sure if the first
> of these issues has caused issues on other 64-bit architectures as
> well.
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.
Sorry for the confusion.
Carl Love
|
|
From: Carl L. <ce...@us...> - 2020-02-13 21:54:12
|
Valgrind developers: The PPC architecture has a number of "new" regression errors. There appear to be two root causes for these issues. Not sure if the first of these issues has caused issues on other 64-bit architectures as well. Bug 416760 - ppc64le Assertion 'VG_IS_16_ALIGNED(sizeof(struct rt_sigframe))' failed https://bugs.kde.org/show_bug.cgi?id=416760 Bug 417427 - commit to fix vki_siginfo_t definition created numerous regression errors on PPC64 https://bugs.kde.org/show_bug.cgi?id=417427 Basically the issue comes from commit: commit 3bac39a10abf292d332bb20ab58c6dd5c28f9108 Author: Eugene Syromyatnikov <ev...@gm...> Date: Fri Mar 8 04:07:00 2019 +0100 include/vki: fix vki_siginfo_t definition on amd64, arm64, and ppc64 As it turned out, the size of vki_siginfo_t is incorrect on these 64-bit architectures: (gdb) p sizeof(vki_siginfo_t) $1 = 136 (gdb) ptype struct vki_siginfo type = struct vki_siginfo { int si_signo; int si_errno; int si_code; union { int _pad[29]; struct {...} _kill; struct {...} _timer; struct {...} _rt; struct {...} _sigchld; struct {...} _sigfault; struct {...} _sigpoll; } _sifields; } etc. The issue is the struct rt_sigframe is not properly aligned. The following patch fixed the issue on ppc64 reducing the number of regression errors from == 649 tests, 38 stderr failures, 13 stdout failures, 1 stderrB failure, 5 stdoutB failures, 2 post failures to == 649 tests, 6 stderr failures, 3 stdout failures, 0 stderrB failures, 2 stdoutB failures, 2 post failures == ----------------------------------------------- --- coregrind/m_sigframe/sigframe-ppc64-linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/coregrind/m_sigframe/sigframe-ppc64-linux.c b/coregrind/m_sigframe/sigframe-ppc64-linux.c index 0406f3c..b54c4e0 100644 --- a/coregrind/m_sigframe/sigframe-ppc64-linux.c +++ b/coregrind/m_sigframe/sigframe-ppc64-linux.c @@ -112,7 +112,7 @@ struct rt_sigframe { vki_siginfo_t info; struct vg_sig_private priv; UChar abigap[288]; // unused -}; +} __attribute__ ((aligned (16))); #define SET_SIGNAL_LR(zztst, zzval) \ do { tst->arch.vex.guest_LR = (zzval); \ -- 2.7.4 --------------------------------------------------- I would like to get some testing done on other architectures to see if it fixes issues on other systems and if it causes any additional issues before committing this patch to Valgrind. Thanks for your help on this. Carl Love |
|
From: Carl L. <ce...@us...> - 2020-02-13 21:53:58
|
Julian:
The second issue that is causing regression errors on PPC64 has to do
with the grail changes as mentioned in some private emails. Currently
there is no bugzilla for this issue.
Specifically the commit in question is:
commit 076a79a48e251067758e1e9d8e50681450ed3889
Author: Julian Seward <js...@ac...>
Date: Wed Nov 27 08:52:45 2019 +0100
'grail' fixes for ppc32 and ppc64:
* do_minimal_initial_iropt_BB: for ppc64, flatten rather than
assert flatness.
(Kludge. Sigh.)
etc.
The patch adds the following code in ir_opt.c
// FIXME2 The TOC-redirect-hacks generators in m_translate.c -- gen_PUSH()
// and gen_PO() -- don't generate flat IR, and so cause this assertion
// to fail. For the time being, hack around this by flattening,
// rather than asserting for flatness, on the afflicted platforms.
// This is a kludge, yes.
if (guest_arch == VexArchPPC64) {
bb0 = flatten_BB(bb0); // Kludge!
} else {
vassert(isFlatIRSB(bb0)); // How it Really Should Be (tm).
}
The issue comes from the new expressions generated by flatten_BB(bb0).
As mentioned in previous private emails, the flatten_BB() generates
V128 expressions for Iex_ITE which is not supported.
The following patch adds the needed support for Iex_ITE for V128
expressions. I kinda get what the Iex_ITE needs to do but don't claim
to completely understand it all or why the kludge calls flatten_BB()
only for the PPC64 architecture. It appears you are planning to remove
the hack once things were "properly" fixed. Not sure if this fix will
be needed for the "proper" fix or not. But either way, it might be
nice to have this additional functionality available.
I need some additional review of this code as I don't claim to
completely understand the grail changes that were being done or if my
fix is OK. With this fix, the PPC64 regression test failures is
reduced to:
== 649 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdoutB failure, 2 post failures ==
gdbserver_tests/nlcontrolc (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
memcheck/tests/linux/rfcomm (stderr)
massif/tests/new-cpp (post)
massif/tests/overloaded-new (post)
As expected.
Thanks for the help on the review.
Carl Love
---------------------------------------------
additional grail' fixes for ppc32 and ppc64
The grail changes introduce a kludge call for ppc64. The call fails
on some tests as the flatten call generates adds
addStmtToIRSB(bb, IRStmt_WrTmp(t1,
IRExpr_ITE(flatten_Expr(bb, ex->Iex.ITE.cond),
flatten_Expr(bb, ex->Iex.ITE.iftrue),
flatten_Expr(bb, ex->Iex.ITE.iffalse))));
for V128 expressions. Iex_ITE isn't supported for V128 type. This patch
adds the needed V128 support for the Iex_ITE expressions.
---
VEX/priv/host_ppc_defs.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
VEX/priv/host_ppc_defs.h | 8 +++++++
VEX/priv/host_ppc_isel.c | 12 ++++++++++
3 files changed, 79 insertions(+)
diff --git a/VEX/priv/host_ppc_defs.c b/VEX/priv/host_ppc_defs.c
index 6c298fa..a58ceb9 100644
--- a/VEX/priv/host_ppc_defs.c
+++ b/VEX/priv/host_ppc_defs.c
@@ -1526,6 +1526,15 @@ PPCInstr* PPCInstr_AvBCDV128Binary ( PPCAvOp op, HReg dst,
i->Pin.AvBCDV128Binary.src2 = src2;
return i;
}
+PPCInstr* PPCInstr_V128CMov ( PPCCondCode cond, HReg dst, HReg src ) {
+ PPCInstr* i = LibVEX_Alloc_inline(sizeof(PPCInstr));
+ i->tag = Pin_V128CMov;
+ i->Pin.FpCMov.cond = cond;
+ i->Pin.FpCMov.dst = dst;
+ i->Pin.FpCMov.src = src;
+ vassert(cond.test != Pct_ALWAYS);
+ return i;
+}
/* Pretty Print instructions */
@@ -2177,6 +2186,27 @@ void ppPPCInstr ( const PPCInstr* i, Bool mode64 )
ppHRegPPC(i->Pin.AvBCDV128Binary.src2);
return;
+ case Pin_V128CMov:
+ vex_printf("v128cmov (%s) ", showPPCCondCode(i->Pin.FpCMov.cond));
+ ppHRegPPC(i->Pin.V128CMov.dst);
+ vex_printf(",");
+ ppHRegPPC(i->Pin.V128CMov.src);
+ vex_printf(": ");
+ vex_printf("if (v128_dst != v128_src) { ");
+ if (i->Pin.FpCMov.cond.test != Pct_ALWAYS) {
+ vex_printf("if (%s) { ", showPPCCondCode(i->Pin.FpCMov.cond));
+ }
+ vex_printf("vor ");
+ ppHRegPPC(i->Pin.V128CMov.dst);
+ vex_printf(",");
+ ppHRegPPC(i->Pin.V128CMov.src);
+ vex_printf(",");
+ ppHRegPPC(i->Pin.V128CMov.src);
+ if (i->Pin.FpCMov.cond.test != Pct_ALWAYS)
+ vex_printf(" }");
+ vex_printf(" }");
+ return;
+
case Pin_Dfp64Unary:
vex_printf("%s ", showPPCFpOp(i->Pin.Dfp64Unary.op));
ppHRegPPC(i->Pin.Dfp64Unary.dst);
@@ -2767,6 +2797,10 @@ void getRegUsage_PPCInstr ( HRegUsage* u, const PPCInstr* i, Bool mode64 )
addHRegUse(u, HRmRead, i->Pin.Dfp128Cmp.srcR_hi);
addHRegUse(u, HRmRead, i->Pin.Dfp128Cmp.srcR_lo);
return;
+ case Pin_V128CMov:
+ addHRegUse(u, HRmModify, i->Pin.V128CMov.dst);
+ addHRegUse(u, HRmRead, i->Pin.V128CMov.src);
+ return;
case Pin_EvCheck:
/* We expect both amodes only to mention the GSP (r31), so this
is in fact pointless, since GSP isn't allocatable, but
@@ -3118,6 +3152,10 @@ void mapRegs_PPCInstr ( HRegRemap* m, PPCInstr* i, Bool mode64 )
mapReg(m, &i->Pin.Dfp128Cmp.srcR_hi);
mapReg(m, &i->Pin.Dfp128Cmp.srcR_lo);
return;
+ case Pin_V128CMov:
+ mapReg(m, &i->Pin.V128CMov.dst);
+ mapReg(m, &i->Pin.V128CMov.src);
+ return;
case Pin_EvCheck:
/* We expect both amodes only to mention the GSP (r31), so this
is in fact pointless, since GSP isn't allocatable, but
@@ -6302,6 +6340,27 @@ Int emit_PPCInstr ( /*MB_MOD*/Bool* is_profInc,
goto done;
}
+ case Pin_V128CMov: {
+ UInt v_dst = vregEnc(i->Pin.V128CMov.dst);
+ UInt v_src = vregEnc(i->Pin.V128CMov.src);
+ PPCCondCode cc = i->Pin.V128CMov.cond;
+
+ if (v_dst == v_src) goto done;
+
+ vassert(cc.test != Pct_ALWAYS);
+
+ /* jmp fwds if !condition */
+ if (cc.test != Pct_ALWAYS) {
+ /* bc !ct,cf,n_bytes>>2 */
+ p = mkFormB(p, invertCondTest(cc.test), cc.flag, 8>>2, 0, 0,
+ endness_host);
+ }
+
+ // move register, use vor dst, src, src op1 = 4, opc2 = 1156
+ p = mkFormVX( p, 4, v_dst, v_src, v_src, 1156, endness_host );
+ goto done;
+ }
+
case Pin_EvCheck: {
/* This requires a 32-bit dec/test in both 32- and 64-bit
modes. */
diff --git a/VEX/priv/host_ppc_defs.h b/VEX/priv/host_ppc_defs.h
index 70c3b6c..f1a97fd 100644
--- a/VEX/priv/host_ppc_defs.h
+++ b/VEX/priv/host_ppc_defs.h
@@ -584,6 +584,7 @@ typedef
* round */
Pin_DfpQuantize128, /* D128 quantize using register value, significance
* round */
+ Pin_V128CMov, /* Vector 128-bit conditional move */
Pin_EvCheck, /* Event check */
Pin_ProfInc /* 64-bit profile counter increment */
}
@@ -1068,6 +1069,12 @@ typedef
HReg srcR_hi;
HReg srcR_lo;
} Dfp128Cmp;
+ /* V128 mov src to dst on the given condition. */
+ struct {
+ PPCCondCode cond;
+ HReg dst;
+ HReg src;
+ } V128CMov;
struct {
PPCAMode* amCounter;
PPCAMode* amFailAddr;
@@ -1188,6 +1195,7 @@ extern PPCInstr* PPCInstr_InsertExpD128 ( PPCFpOp op, HReg dst_hi,
extern PPCInstr* PPCInstr_Dfp64Cmp ( HReg dst, HReg srcL, HReg srcR );
extern PPCInstr* PPCInstr_Dfp128Cmp ( HReg dst, HReg srcL_hi, HReg srcL_lo,
HReg srcR_hi, HReg srcR_lo );
+extern PPCInstr* PPCInstr_V128CMov ( PPCCondCode, HReg dst, HReg src );
extern PPCInstr* PPCInstr_EvCheck ( PPCAMode* amCounter,
PPCAMode* amFailAddr );
extern PPCInstr* PPCInstr_ProfInc ( void );
diff --git a/VEX/priv/host_ppc_isel.c b/VEX/priv/host_ppc_isel.c
index 9c954da..25ab559 100644
--- a/VEX/priv/host_ppc_isel.c
+++ b/VEX/priv/host_ppc_isel.c
@@ -5587,6 +5587,18 @@ static HReg iselVecExpr_wrk ( ISelEnv* env, const IRExpr* e,
vassert(e);
vassert(ty == Ity_V128);
+ if (e->tag == Iex_ITE) {
+ HReg r1 = iselVecExpr( env, e->Iex.ITE.iftrue, IEndianess );
+ HReg r0 = iselVecExpr( env, e->Iex.ITE.iffalse, IEndianess );
+ HReg r_dst = newVRegV(env);
+
+ // Use OR operator to do move r1 to r_dst
+ addInstr(env, PPCInstr_AvBinary( Pav_OR, r_dst, r0, r0));
+ PPCCondCode cc = iselCondCode(env, e->Iex.ITE.cond, IEndianess);
+ addInstr(env, PPCInstr_V128CMov(cc, r_dst, r1));
+ return r_dst;
+ }
+
if (e->tag == Iex_RdTmp) {
return lookupIRTemp(env, e->Iex.RdTmp.tmp);
}
--
2.7.4
|