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
(5) |
2
(10) |
3
(9) |
4
(8) |
5
(2) |
6
|
|
7
|
8
(1) |
9
(4) |
10
(2) |
11
|
12
(1) |
13
(2) |
|
14
|
15
(7) |
16
(1) |
17
(9) |
18
(1) |
19
(4) |
20
(4) |
|
21
(1) |
22
(3) |
23
(1) |
24
|
25
|
26
|
27
|
|
28
|
29
(2) |
30
(2) |
31
(6) |
|
|
|
|
From: Eyal S. <eya...@gm...> - 2021-03-03 19:40:48
|
From: eyal0 <109...@us...> This fixes https://bugs.kde.org/show_bug.cgi?id=432801 To test: ```sh make && perl tests/vg_regtest memcheck/tests/x86/pcmpgtd ``` --- memcheck/mc_translate.c | 92 +++++++++++++++++++++++++- memcheck/tests/x86/Makefile.am | 7 ++ memcheck/tests/x86/pcmpgtd | Bin 0 -> 19688 bytes memcheck/tests/x86/pcmpgtd.c | 25 +++++++ memcheck/tests/x86/pcmpgtd.stderr.exp | 10 +++ memcheck/tests/x86/pcmpgtd.vgtest | 2 + 6 files changed, 135 insertions(+), 1 deletion(-) create mode 100755 memcheck/tests/x86/pcmpgtd create mode 100644 memcheck/tests/x86/pcmpgtd.c create mode 100644 memcheck/tests/x86/pcmpgtd.stderr.exp create mode 100644 memcheck/tests/x86/pcmpgtd.vgtest diff --git a/memcheck/mc_translate.c b/memcheck/mc_translate.c index 516988bdd..934edf37c 100644 --- a/memcheck/mc_translate.c +++ b/memcheck/mc_translate.c @@ -1287,6 +1287,92 @@ static IRAtom* expensiveCmpEQorNE ( MCEnv* mce, return final_cast; } +/* Check if we can know, despite the uncertain bits, that xx is greater than yy. + We can combine xx and vxx to create two values: the largest that xx could + possibly be and the smallest that xx could possibly be. Likewise, we can do + the same for yy. We'll call those max_xx and min_xx and max_yy and min_yy. + + If max_xx is is not greater than min_yy then xx can't possibly be greater + than yy so we know our answer for sure. If min_xx is greater than max_yy + then xx is definitely greater than yy. For all other cases, we can't know. + + For unsigned it's easy to make the min and max: Just set the unknown bits to + all 0s or all 1s. For signed it's harder because having a 1 in the MSB makes + a number smaller! It's tricky because the first bit is the sign bit. We can + work around this by changing from 2's complement numbers to biased numbers. + We just need to xor the MSB of the inputs with 1. Then we can treat the + values as if unsigned. + */ +static IRAtom* expensiveCmpGT ( MCEnv* mce, + unsigned int word_size, + Bool is_signed, + unsigned int count, + IRAtom* vxx, IRAtom* vyy, + IRAtom* xx, IRAtom* yy ) +{ + IROp opAND, opOR, opXOR, opNOT, opEQ, opSHL, opGT; + IRType ty; + + tl_assert(isShadowAtom(mce,vxx)); + tl_assert(isShadowAtom(mce,vyy)); + tl_assert(isOriginalAtom(mce,xx)); + tl_assert(isOriginalAtom(mce,yy)); + tl_assert(sameKindedAtoms(vxx,xx)); + tl_assert(sameKindedAtoms(vyy,yy)); + + switch (word_size * count) { + case 128: + ty = Ity_V128; + opAND = Iop_AndV128; + opOR = Iop_OrV128; + opXOR = Iop_XorV128; + opNOT = Iop_NotV128; + break; + default: + VG_(tool_panic)("expensiveCmpGT"); + } + if (word_size == 32 && count == 4) { + opEQ = Iop_CmpEQ32x4; + opSHL = Iop_ShlN32x4; + if (is_signed) { + opGT = Iop_CmpGT32Sx4; + } else { + opGT = Iop_CmpGT32Ux4; + } + } else { + VG_(tool_panic)("expensiveCmpGT"); + } + IRAtom *MSBs; + if (is_signed) { + IRAtom *const0 = mkV128(0); + IRAtom *all_ones = assignNew('V', mce, ty, binop(opEQ, const0, const0)); + MSBs = assignNew('V', mce, ty, binop(opSHL, all_ones, mkU8(31))); + vxx = assignNew('V', mce, ty, binop(opXOR, vxx, MSBs)); + vyy = assignNew('V', mce, ty, binop(opXOR, vyy, MSBs)); + // From here on out, we're dealing with biased integers instead of 2's + // complement. + } + IRAtom *not_vxx = assignNew('V', mce, ty, unop(opNOT, vxx)); + IRAtom *not_vyy = assignNew('V', mce, ty, unop(opNOT, vyy)); + IRAtom *max_xx = assignNew('V', mce, ty, binop(opOR, xx, vxx)); + IRAtom *min_xx = assignNew('V', mce, ty, binop(opAND, xx, not_vxx)); + IRAtom *max_yy = assignNew('V', mce, ty, binop(opOR, yy, vyy)); + IRAtom *min_yy = assignNew('V', mce, ty, binop(opAND, yy, not_vyy)); + if (is_signed) { + // Now unbias. + max_xx = assignNew('V', mce, ty, binop(opXOR, max_xx, MSBs)); + min_xx = assignNew('V', mce, ty, binop(opXOR, min_xx, MSBs)); + max_yy = assignNew('V', mce, ty, binop(opXOR, max_yy, MSBs)); + min_yy = assignNew('V', mce, ty, binop(opXOR, min_yy, MSBs)); + } + IRAtom *min_xx_gt_max_yy = assignNew('V', mce, ty, binop(opGT, min_xx, max_yy)); + IRAtom *min_yy_gt_max_xx = assignNew('V', mce, ty, binop(opGT, min_yy, max_xx)); + return min_xx_gt_max_yy; + // If either of those are true then all the bits are defined. + IRAtom *either = assignNew('V', mce, ty, binop(opOR, min_xx_gt_max_yy, min_yy_gt_max_xx)); + // We need to invert because for us, defined is 0. + return assignNew('V', mce, ty, unop(opNOT, either)); +} /* --------- Semi-accurate interpretation of CmpORD. --------- */ @@ -3947,9 +4033,13 @@ IRAtom* expr2vbits_Binop ( MCEnv* mce, case Iop_PwExtUSMulQAdd8x16: return binary16Ix8(mce, vatom1, vatom2); - case Iop_Sub32x4: case Iop_CmpGT32Sx4: + return expensiveCmpGT(mce, 32, True /* signed */, + 4, vatom1, vatom2, atom1, atom2); case Iop_CmpGT32Ux4: + return expensiveCmpGT(mce, 32, False /* unsigned */, + 4, vatom1, vatom2, atom1, atom2); + case Iop_Sub32x4: case Iop_CmpEQ32x4: case Iop_QAdd32Sx4: case Iop_QAdd32Ux4: diff --git a/memcheck/tests/x86/Makefile.am b/memcheck/tests/x86/Makefile.am index 557de6b11..f5c04ee90 100644 --- a/memcheck/tests/x86/Makefile.am +++ b/memcheck/tests/x86/Makefile.am @@ -13,6 +13,7 @@ EXTRA_DIST = \ $(addsuffix .stderr.exp,$(INSN_TESTS)) \ $(addsuffix .stdout.exp,$(INSN_TESTS)) \ $(addsuffix .vgtest,$(INSN_TESTS)) \ + pcmpgtd.stderr.exp pcmpgtd.vgtest \ pushfpopf.stderr.exp pushfpopf.stdout.exp pushfpopf.vgtest \ pushfw_x86.vgtest pushfw_x86.stdout.exp pushfw_x86.stderr.exp \ pushpopmem.stderr.exp pushpopmem.stdout.exp pushpopmem.vgtest \ @@ -37,6 +38,7 @@ check_PROGRAMS = \ fprem \ fxsave \ more_x86_fp \ + pcmpgtd \ pushfpopf \ pushfw_x86 \ pushpopmem \ @@ -52,6 +54,11 @@ AM_CCASFLAGS += @FLAG_M32@ # fpeflags must use these flags -- bug only occurred with them. fpeflags_CFLAGS = $(AM_CFLAGS) -march=i686 + +# pcmpgtd failure only occurs with clang version >= 10 and -O2 +pcmpgtd_SOURCES = pcmpgtd.c +pcmpgtd_CFLAGS = -O2 + pushfpopf_SOURCES = pushfpopf_c.c pushfpopf_s.S if VGCONF_OS_IS_DARWIN pushpopmem_CFLAGS = $(AM_CFLAGS) -mdynamic-no-pic diff --git a/memcheck/tests/x86/pcmpgtd b/memcheck/tests/x86/pcmpgtd new file mode 100755 index 0000000000000000000000000000000000000000..87c0185f0909c5a1c8e6db6ece1dff78dae491a1 GIT binary patch literal 19688 zcmeHPe{dYteSdp<ds<8K-AVEf*(UhF25eKGBwH9^8~aX{>=g(j`~xt?UQYKzcldtg zZqHaGLrrDVTpLr9W~OdB0j8Z{+?oE!KdA`~VAn1-B%PYz2?RpN5JOE8u+sub3E}$r zzJ2d>x0WZ&q|@n4?`igZe}CWiefRC|d%O4a`-8*lU5dhFaj`Xws1bjNv+SC&MFX4^ zygt^#LTmxMnt8x+;|OsHK^v1W>9Pe9>OxNiB)h{xe%KWPMRbS&yMot~P)10Q>?TV{ zpf-F`2qk2GTTFHup@L?je-ge)0ij4J^{VX!xR|j($VLRbPXs1mtsUit1#NY<CS)T5 z_KALn1eA6}lAT}J`GvlOXGMDw%6w9{={O<$op6Of5gj7H26#OQNtepVJ64Qve}E{0 zp*pylQ;bO{?e2gb@1KzWHXzf!NwjylyfB#$0Y!INS2{JiqPHs@TbfQ~OM8~?>07aM zMQ^Z}3ohgRCjX?nVdGXF3Y|{riejFDgLovr<J~VlkUsfr)9fdwC$IbS_QziD82%c` zXnc?^;j&$zyhvZfmxmC2F3=7wI-I2ijH&onT!z0A`~Z$i3i1=BbgW=StB{UoSur&h ziCU>#mYF6A&7u`4SY{@Y%CZf^L;dT_Wx-{^8z3Fa<g!9)l3y49vs+NmTk5Yof2Fyp zX`~^C^~JRzu1I5n@+Ql#YWQ-@kgPKl;wnw3$*(Md8otc6lr>-@1C0zcGSJ9CBLj^L zG&0c0KqCW<4E)bzz?k^CZv3(KeiviL{-c(wa@v?Up&ze0uiWr9M3rmKq4v!W0V6s| z^7qbGP_B8MXqw8ucN%2R`$OfIcN*oljfry?N45-|JbJn##Eg^2@*JEDwZX^C-LU!4 zH-CV!<B6be{yyFur=RY_LcqA0YOCXE;!{}Do+n1-Y~tYYM6E%HJ;(JQ{(ysHpQ%Rq zqH*l}T0?okc=<D{t?HpkcyQY9y}1Xmu+r?UM){rd51|JyX!F5Qb{rS+)wlPvN9*aW zn~jHmewe~Muw|kDc^|NzkI(<`vr6UJR^SuAQhfV9Ms|AMs8jeh6u9hl$c(2Im+IC$ zO}bHbFHD>qSg229M)}{*KLM>51{Nxm1K+;CCDrnAgWK&V;=oAdJAmvTsWK)$QGJix z%avX>Cf@qgI57UHQU1(0_JPZoctI(DH1UpN?63ItJx|)@3&!GKK1YTL!<T&_;k)o6 zonPOPD|!>Y>?;Z1eLqO}BCq?7+}rD_VSstzT*8<5Ny1n7NoT@0`s0M}%xhpC1@oW4 ze4Ci3!F-ua-7q~4Uyw$Q62k+=_rQ1&3>@6oS(u$AvlB3b_Jud#>qlU|MNDX)c?liR zjfs;k-~R15ML+Y_2X5?t-@4Uz<jXwLS4HR)DID<@-j;!#A!oiLz0}7aPAVo|mkQ|k z8Fb^!v4k&wY9o+SNY6vxGj4jxnrTeDs2INIX0#g0E5^hz#klEI>4Nc{fBC*$jPh&7 zFW)kb{Zv(caKQbw#mCEUmd_gxpP<pPeFyqQ<2`)WQ2EvHokQi1!&}4U--NdeAGl`E z62`U~2bL1tJiPcFx+c#@Kdn@ZW4}?Yc|C9V=Ck4QC&T5B2g(=1l^H)aCXS==H%mXI zYjyjM@V((3;hkX<BbL#X%dhFWs~F5iX=I?0fkp-z8E9mnk%2}A8X0J0ppk+9_Zd*| zEl;jK@nMfC^VC)Jt(Sj;zF4Uo0v-aq8!!(@OZDzwR4PXS@B7b6<s#rwz&=_@qR@9% zD$0YKn6k&O%xi7Z4=PQ5`hG~?G|yhBRIVoll&N*?Z;hmT4!XiETL`)vM;<(a%<Et8 z?Yza;@_@dVt)07S$?}C)6Z`jYP^?MBy2J$}?DdDeog2JIl?n9`mwKhk+sRqt!#S2@ z>?@@IAC<}uK-TZ||A}kR+xe(E=nWij4|*4URWrQZk9Z7k-$c^}Z|Ht+U)b9n_Acu8 z2Kv37(C_!^{QKx>nD2!j88f+Sltu;`8E9mnk%2}A8X0J0ppk(_1{xV?WZ?fw2D<S* zmKOo#+C@V8h{=oiz4UZJp26o_Dsy;^YE6h^^8_uHS8T4Ng`C!PRHWQ(lT24b9Q)|A zN{*0jLG#~igFYo_`J3YrK{s<N#)br>-_ug*v;mtbpaj+5sN#Dv6<Q)v;cH4jxhAFG zr&5`11D1D(I41caLCbzfds;(Nk?rFPF7Ho3=;P}prxja`VVTP5b|Dw+|1}_gSMF?Z zg*e~q1$4?ctXsD-uxKDYnu=rteZl3y?xiah+X#!MBiXUQ?s%byUmpj0x`X&z+WSyu zPtQ%)_XOBRoOAoM>pTmsY`*Zm7?6G-K!q0Xu0H~zTpUEL@@kl{$LSopgOF=(?GE6c zJ5e=}?jhGaeH-BYI9%7VX}W8^o&o+hL|@JHKLn&Nq^^Y+f$i{+f-hH4*KY<+Ex3BV zqOS*ji1@t+S@RJv_ux<r?YjUiJPxLvs^aR8fT{x&llE_@n%_gE!-e|g*1hUN{p%ok z?AJ2=n-X8-)}NC25?%j0iFdc^-v+)Ic~QUQpO#mb>-4eyJh{7p>93I<$yT#gUG3AU zy<d}TCDY#r?m-mlDmT+V1(7Ai0oLkQ*Xk;89z>Yw%@Xf->ob9OlF>Sy>1#mz6%KWn zj5bVqAFA<wOO4U3FzScFYh-jMYYnKkPa54(W3<Vw-wGWb!De0GN;tK;#jk%+;#)hJ z{ve2Js6Q!kwoTs$nlh_yXZlxx-$nQiU4I<-ZKRj<PxGrg^`}7ZAUaNwNAzz=yC~C- zNIZsU>1P8w$;lWJr2i|ZuajAx%+fmbV}ztxrk@4Q<ITbBT@cTb;y5W<`UjwST)Ub6 zUsCY_U3WpJjU4Qu+vaq#_kIZ870h>n8f<DN);l=dhnh+8LqZR_sn1RB<^|v^hdb>` ze<y&hb?WnlcWo}yX;e_F8t$=e%@pVuIPPz_cLHd-`w#&a_j`f_i<>RzEQ4>4-n!SL z>2rbZ2g`$-*!0JM@ZkK+9iaAg?VDh=YjiPn)Lw<kU7NU^VxQr9%zqbA&7=m3Z6~Td zhzpwEYH6QOQ%9J{d!VtK$eHUw&U#8**nff8W-fp%L$X;UW3!i_x<@E*;!A>H(^o=) z2inZsQJ8oX55?Y0RSvWsWJ;TIjkiNnz5dzrylqOmhc0SG^{#AL)pFgOp^nva*5Wy( zYHX+jd0EI*@0yktJSj9E=XkE=ps52UEiGgOuhXG5)Imfa$Z4|`DQTVsZQD2Q2Q!uH z;JUS=DxR(=)Qa~iXx#`)A2rv~vIeMsc1;6qK6JT#CL{BXAbQa533dKi{~X)%PzOak zqnEilB?DOlIeU_v)xxciz49L@tf!+5iDl2znP(bmMNxk3olb!G#ONv&3tg#fG+m0t zSuN3p-8ANkUa_@iEL-XtO<Bdyq0(iI=i@>VdrZ30>D`&7J>9ffr;9%Yy6n4uwN=`c zl8vN;NeZaCLj@#GB*;`YkuxojIJexjEip~Vc1O}u#OY$(l5{?r$&XpFU=$t2_Lo>J zo`4|@EO!%|=8}VXuGZB2nnx`?qb*Qd?$(-CtEGfT^;+5j&oe|75}NK&+aK2guWJ5n zns$%Y`k1Dz(tNI+9a^i$wX9w9-J-SXHgGMMq?*!KYd&?h9@JW0*9z`4n&uhusQ2p$ z&F4{P!_ITJcC}}fHrI2Drma@*4-&ugaSeCvBwQ*UbxzRLiu3hb9-ot)?Mmh{@ve9= zmyC4f3#r`^E8c}HjTKVaSXU;Vi6-OGU0qhZXcg%UW2a9w<7P6FjiuuSR*Y0pE*5;# zB1u&p=Z1)Ej*xhvU?b5S#*t~}Be8A<aUvB@$BK+-aKoE6g}0fThwd3Pw`?03G)-pi zN~P1}AfF-y)YMAKEO8PwNYhGXD5?~Y7=aw75rq=%W}*PlJ76>tQdzPkEN>O;o)G~L z1sqU~Cez#jc0F08BH5S7H%sR*Hz8}&jHYwZU3LsbE+e}{q?G1iMPe}?2thMl9A(91 zj(m^iN?GbA=Z|L5m2~a_#B7%Gc>?)e@o_jWp^fFsC?Gh^=j@)3BI^`N0#;xb$KfX$ zNvF9pu*Qo-!FM5=gr2w_=u~7P#a-}93E({_Wg*VSW1=hMjIIY#O{61Z=y1d=;LPU= zh>7p{!e%g*k62c`kY&+iq`>mDODu(E9*n~<nP(BYd{Df&7^x_1#6~9Tgg`ISJq5+Z zx}W$+;7ZkOlP#RAKcCs=NrTUYsfh5fD|Csjim*;h$yeFADfyT(sZ;sUs_T&2MpS$q zlk1Oqep7XwQqR}fRP%e4O=EIhP_N(2<ocqX-%?$N)blajm|~u;vgs@^CEr`!-&^m; z$K<-Mp6_SXeXlhFm9<s(i`KAl^KNG&flw`r<0`|0QLF=Ng(_BE`jq^cY^wE%%4RXS z@37tvR%@Y9EsNtSR%45%<j-OByJ2ThtE<*}iOS^a*2%x3o*^ieec>|vD=)*B3!zCd zU0ZJUi^?R&#%O}+VqSL8aelpmf7HRhO7K}*2-sw~5vYPyyv&2Rmf3pFzx2G&YKq#e zzBdrA#<~8b=l2l!Q^kL|e*Go))6VX_Dg>;)Oy%cWT&3fZ@pBA(1yfSz_<2d_JICRh zoPX(fzR3MtI<7qEKs)k4ziy`@^Ogb<m}0!m;`&^*u38GdANn%?Qs^gr*QM8E?`8ZL zm*LYAf&4qizXg6kHdX^Cz;APPvTnz9agg}*l{*mP+BCVM@&x#l2l{zG75)t!@Vhwt z7*`>OpT8%4mzV7o;}aw=8R19%-+}7||0MY2$C;m3gua~H(dz;#w1%Vjo%(-G`j}oZ z$92J?1*>S4u&W@-V(~(JELFr4(zG%(JIG>gYnri~IhM|iVs;V3<Fsf-N_$u|m%-!H zipPRCE?-7_sHade6RB(pkMcrf+>B?f!Z=G5BAK`uD`he?L#UxJok>}Bs*|%k(_FtP zeA}QoxN(3cQT3{rM+|J+7`|<2UA=_w^#%*u-OWKmcrXSwF>}N4?fv0l^Y-=YHxF(x zw}ktL2gxhnAs#K3c+fQUu=kFKLUmik<FSYp5gW`MBIh1+r<g45P3CB=ZpS&2SImi7 zC^Ls{hgK|=HA}@fO%tnuQHq!uOJiDtc^l@s<jqP&F_ENM=xDJh-1FIvX>Pe~oyZvr z7RNJIWE9XU*f1$E%+lh8JPT%XRy-K)A6jZf#sr0RP;j)A!oM8AR5VCbGEz*kU~D`K ze>TM2lS{<Qt~$bm46#PYKwx=HErYxxK`XuoI1LfVay+lWcv1|CB&MEK%C@jahixHo zIF4jeQM8(aFH}L^fb9$kVL^=348|UUjgOYbFm@6-iAP393-R5O!hcnWOB}h8C^Btd zSHEjbPflEdcy`!D&fDbw|8PD*Nw>Bv0736wrM;Zr$^Ul|s8t3o?@yB51Ekho&I8X0 zhYO{mfKGb@d<}<eU(OeG)izip?C|P=7hOQ<X8`oac-JfKyVVfa=oa>}|4w`1hHV6b zR|wVi<@}Rg15u%OlvJpXlsnmeCoxgzbq%S?_D_lSPYL@WQmQG={O^Q}-d#(3IiGD8 z9c&i1GJdHi;V#JOUAUy>yf+~11H#@JzhJWmfsm@Sm-FM0u<sU%vVCX&_X+!cp(o$x z=clm8)BckDJqjM>MEb8jNAO6bLN>KUxUI6vz-sLS;yDx$_A-8HAlUT8<%M1&*V@bH z<cLssSe!?pUbU0-HyrkIo__{YHY(F>P_3QuKM4u7FY_<w0W1I}3e7ufi_`uvgthjQ z|7XUwT3u@l+-d(04tu%27zx;hG+(MM^88EQQ6Lm!HBD<mpiqJ~aOz81!tX<k-q=Zd zxn9BBM_#0!O-+s;$){KMG<KxDoR`Y~^K(|jPvf78w3FxmE$~Q1+ROFN#V*pOIZ}O* z_7c7eajkuIoz!jHEvh%KwlD23IPB$oa*?pVT>H}PM?lDzj9<>r`h>k~N9v1oNRoX5 zjCex5%9r-5svH}U_7c(;5Q*2S7KOu2jsfS?^<BpPpL=a@Ee-<*$-ZzI`_nhr_QxFt z4w8QoBA&DVe@Y8Dl=13?Y17hPLRvRS+}5z`)|EDVtd<GfsY|q@32yPEu)j~-7_S1C op0)CP%I6Q=U*x&xhO!FV$T>%Y4iamRsqN2+8~R#@frDiK4ffTmCjbBd literal 0 HcmV?d00001 diff --git a/memcheck/tests/x86/pcmpgtd.c b/memcheck/tests/x86/pcmpgtd.c new file mode 100644 index 000000000..f9580dd6b --- /dev/null +++ b/memcheck/tests/x86/pcmpgtd.c @@ -0,0 +1,25 @@ +#include <signal.h> +#include <string.h> +#include <stdio.h> +#include <stdlib.h> +#include <math.h> + + +int main() +{ + struct sigaction act; + if (sigaction(SIGTERM, 0, &act) == 1) { + return 12; + } + if (sigaction(SIGTERM, 0, &act) == 1) { + return 12; + } + + char pattern[] = "\x1\x2\x3\x4\x5\x6\x7\x8\x9"; + const unsigned long plen = strlen(pattern); + pattern[1] = 0; + size_t hp=0; + for (size_t i = 0; i < plen; ++i) + hp += pattern[i]; + return hp % 10; +} diff --git a/memcheck/tests/x86/pcmpgtd.stderr.exp b/memcheck/tests/x86/pcmpgtd.stderr.exp new file mode 100644 index 000000000..eb42921c6 --- /dev/null +++ b/memcheck/tests/x86/pcmpgtd.stderr.exp @@ -0,0 +1,10 @@ + + +HEAP SUMMARY: + in use at exit: 0 bytes in 0 blocks + total heap usage: 0 allocs, 0 frees, 0 bytes allocated + +For a detailed leak analysis, rerun with: --leak-check=full + +For lists of detected and suppressed errors, rerun with: -s +ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) diff --git a/memcheck/tests/x86/pcmpgtd.vgtest b/memcheck/tests/x86/pcmpgtd.vgtest new file mode 100644 index 000000000..3b8416530 --- /dev/null +++ b/memcheck/tests/x86/pcmpgtd.vgtest @@ -0,0 +1,2 @@ +prog: pcmpgtd +prereq: test -e pcmpgtd -- 2.20.1 |
|
From: Eyal S. <eya...@gm...> - 2021-03-03 18:00:05
|
On Wed, Mar 3, 2021 at 6:54 AM Mark Wielaard <ma...@kl...> wrote: > Hi Eyal, > > BTW. I did see your other patch for bug #432801 but haven't had time to > dive into that yet. The expensive compare stuff is slightly voodoo to > me. I'll get to it eventually if I dare and nobody else beats me to it. > Sure, when you're ready. The bug report is rather long but has a lot of details: https://bugs.kde.org/show_bug.cgi?id=432801 Also, there is a comment in the patch itself that is pretty long and describes the technique used. I was looking through memcheck again and saw another place where a similar technique is used so I will refactor the code so that they two can share more of the logic. > BTW. The patch as attached doesn't really apply, best to sent it with > git send-email. Or create a bugzilla and attach it there. > I'll do that from now on. > So I think you patch is correct. I just wonder if this should just > impact clo_exit_on_first_error or also the other actions in > do_actions_on_error. Does it make sense to invoke vgdb if the error > doesn't count, or to generate a suppression? > Good question. We could think about that and maybe adjust it, too. Or, we could just make this change and then do the vgdb part in a future commit. One advantage of doing it separately is that if we change our minds about just one or the other then it will be easier to revert in the future. Eyal > Maybe we should simply not call do_actions_on_error when count_error is > false? Also in my attached patch, but I like to hear other opinions, > maybe my assumption that a non-counted error is not interesting for > vgdb (or suppression generation) is flawed. > > Cheers, > > Mark > |
|
From: Carl L. <ce...@us...> - 2021-03-03 16:32:42
|
Mark:
I was using the IBM AT toolchain. This contains newer glibc, gcc, gdb
etc. then the distro. It is basially more on an internal bleeding edge
release of the tool chain. Initially, the install of the AT toolchain
did not include the debug info. Once I installed the debug info
package the Helgrind packages worked. From what I am told, the debug
info contains all of the debug info for all of the executables. So I
can't really say symtab symbols or the full .debug sections.
Carl
On Wed, 2021-03-03 at 13:31 +0100, Mark Wielaard wrote:
> Hi Carl,
>
> On Tue, 2021-03-02 at 11:15 -0800, Carl Love wrote:
> > Additionally, we have noticed a number of helgrind failures in our
> > > testing on the latest internal prototype hardware with the latest
> > > internal compiler. We are investigating these
> > > issues. Currently,
> > > they
> > > do not appear to be related to the ISA 3.1 support. We will
> > > update
> > > you
> > > on these issues as we dig into them further.
> >
> > The issue was the debug info was not installed. Once the debug
> > info
> > was installed the regression tests run without any helgrind
> > failures.
>
> Which components need to have debuginfo installed (valgrind, glibc?)
> to
> get this working as intended? If it is valgrind then it is likely a
> packaging bug (the vgpreload files should not be stripped). If it is
> glibc then it might be interesting to know whether it relied on the
> symtab symbols or the full .debug sections.
>
> Thanks,
>
> Mark
|
|
From: Mark W. <ma...@so...> - 2021-03-03 15:03:00
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=23223e28a5ce1a62ee7cf0a7c578d6c0c8f0136b commit 23223e28a5ce1a62ee7cf0a7c578d6c0c8f0136b Author: Mark Wielaard <ma...@kl...> Date: Wed Mar 3 16:02:33 2021 +0100 Add an entry on the new --track-fds=all option to NEWS. Diff: --- NEWS | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index fa7c4b0183..8595a9034a 100644 --- a/NEWS +++ b/NEWS @@ -43,10 +43,19 @@ support for X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux. * ==================== TOOL CHANGES ==================== -All the tools and their vgpreload libraries are now installed under -libexec because they cannot be executed directly and should be run -through the valgrind executable. This should be an internal, not user -visible, change, but might impact valgrind packagers. +* General tool changes + + - All the tools and their vgpreload libraries are now installed under + libexec because they cannot be executed directly and should be run + through the valgrind executable. This should be an internal, not user + visible, change, but might impact valgrind packagers. + + - The --track-fds option now respects -q, --quiet and won't output + anything if no file descriptors are leaked. It also won't report + the standard stdin (0), stdout (1) or stderr (2) descriptors as + being leaked with --trace-fds=yes anymore. To track whether the + standard file descriptors are still open at the end of the program + run use --trace-fds=all. * DHAT: |
|
From: Mark W. <ma...@kl...> - 2021-03-03 13:54:28
|
Hi Eyal, BTW. I did see your other patch for bug #432801 but haven't had time to dive into that yet. The expensive compare stuff is slightly voodoo to me. I'll get to it eventually if I dare and nobody else beats me to it. This patch seems more easy to understand. I added Philippe to CC to see if he has an opinion on how this should/shouldn't interact with vgdb. On Tue, 2021-03-02 at 15:04 -0700, Eyal Soha wrote: > When I run Valgrind memcheck, I can specify which errors are not cause for > returning the error exitcode but using the error-for-leak-kinds flag. But > when --exit-on-first-error is set to yes, Valgrind will exit early with an > error code even though it would not have caused an error had that option > been absent. This will confuse users. It also makes --exit-on-first-error > useless for integration tests. > > The patch fixes it. > https://github.com/eyal0/valgrind/pull/1/commits/6f06799abd8d1e51764d86ee239fd7fce07374ea BTW. The patch as attached doesn't really apply, best to sent it with git send-email. Or create a bugzilla and attach it there. I did fix up the line lengths (see attached). So for this to work you pass count_error from VG_(unique_error) to pp_error, which passes it onto do_actions_on_error. The other pp_error errors are adjusted to always pass True for count_error. VG_(unique_error) is called by MC_(record_leak_error) which passes count_error to true only for errors-for-leak-kinds (and print_errors to true for show_leak_kinds). So I think you patch is correct. I just wonder if this should just impact clo_exit_on_first_error or also the other actions in do_actions_on_error. Does it make sense to invoke vgdb if the error doesn't count, or to generate a suppression? Maybe we should simply not call do_actions_on_error when count_error is false? Also in my attached patch, but I like to hear other opinions, maybe my assumption that a non-counted error is not interesting for vgdb (or suppression generation) is flawed. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2021-03-03 12:31:59
|
Hi Carl, On Tue, 2021-03-02 at 11:15 -0800, Carl Love wrote: > Additionally, we have noticed a number of helgrind failures in our > > testing on the latest internal prototype hardware with the latest > > internal compiler. We are investigating these issues. Currently, > > they > > do not appear to be related to the ISA 3.1 support. We will update > > you > > on these issues as we dig into them further. > > The issue was the debug info was not installed. Once the debug info > was installed the regression tests run without any helgrind failures. Which components need to have debuginfo installed (valgrind, glibc?) to get this working as intended? If it is valgrind then it is likely a packaging bug (the vgpreload files should not be stripped). If it is glibc then it might be interesting to know whether it relied on the symtab symbols or the full .debug sections. Thanks, Mark |
|
From: Mark W. <ma...@kl...> - 2021-03-03 12:28:57
|
Hi Philippe, On Mon, 2021-03-01 at 21:40 +0100, Philippe Waroquiers wrote: > I would like to work on 2 things: > * look at the nlcontrolc test, and change it so that it does not > depend > anymore on the modification of the select arguments. Yes, this https://bugs.kde.org/show_bug.cgi?id=432870 is a bit of a puzzle. It is also on my list, but I haven't made much progress. I must admit that I don't fully understand how/why it worked before. It seems to rely on valgrind installing signal handlers as SA_RESTART. But even that assumption doesn't really hold since in theory the select call should always return with EINTR instead of being restarted. If you could come up with a testcase that didn't rely on what seems to be magic select behavior that would be great. BTW. See also this arm64 bug report, that is probably the same issue: https://bugs.kde.org/show_bug.cgi?id=338633 > * I would like to do a small change in the way memcheck reports information > about a block. > Currently, a block is described like this: > ==21152== Address 0x4a2f100 is 96 bytes inside a block of size 100,000 alloc'd > > I would like to change it so that it contains the block address. > I was thinking to the following format: > ==18441== Address 0x4a2f100 is 96 bytes inside the block[size] 0x4a2f0a0[100,000] alloc'd > (i.e. uses a format similar to what the monitor command 'block_list' produces. > > It is of course possible to calculate the block address from the given address > and the block offset, but this is annoying/time consuming, in particular when you > do a lot of 'who_points_at' under gdb+vgdb to investigate a logical leak. > > So, I would like to make this easier by having the address and size of a block. > There are other places where I would like to use the same format e.g. instead of > having who points at telling: > ==21496== Searching for pointers pointing in 16 bytes from 0x4a2f3b0 > it could rather show: > ==21496== Searching for pointers pointing in block[size] 0x4a2f3b0[16] > > Feedback welcome before I start to change the block description (and tests) ... Although having the actual block address in the warning message would be really nice I would be a little afraid this would invalidate most/all memcheck testcases unless you can come up with some smart filtering. If we are discussing the color of the bikesed, wording of the warning message then I think I would prefer: Address 0x4a2f100 is 96 bytes inside block 0x4a2f0a0 size 678 Also make sure that the "0 bytes inside" case comes out right/isn't confusing. I think that it might be better to postpone this change to after 3.17.0 is released so we have some time to play with it. Cheers, Mark |
|
From: Mark W. <ma...@kl...> - 2021-03-03 12:12:38
|
Hi Will, On Mon, 2021-03-01 at 10:01 -0600, will schmidt wrote: > I would like to see the remainder of the power10 enablement patches > make it in. I *think* this is now down to two updated and pending > revised review patch sets, > 429354 , 429375 > > The SCV and DARN bugs would > ideally be resolved, but they will take as long as they take. So they are currently both masked out from HWCAP2 which hopefully signals to applications that they should not use them. I don't believe anybody has tried implementing DARN yet (bug #411189). Maybe it can use the same trick as adm64 RDRAND as implementation? For SCV (bug #431157) testing has been a little tricky since you need the latest glibc, kernel and a power9 setup. I did test Carl's latest patch for SCV support on that, but found it still had some argument/return value passing issues. > There is > one additional patch set for power10 support that enables a small > number of instructions that we can not yet verify on our early > hardware. That patch needs to be posted for review. The window of > that one is shrinking,.. It would be nice to get the power10 patches completed before 3.17.0 is released, but testing that is even harder than the SCV issue. There are also patches waiting for s390x z15, x86_64 avx512 and of course the freebsd support. So if things don't make it for 3.17.0 lets try to do a 3.17.1 or even 3.18.0 release sooner (in 3 or 6 months). Cheers, Mark |
|
From: Paul F. <pa...@so...> - 2021-03-03 07:57:28
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=c136213d4618b717cda1d6932f707de1c7b3fd6c commit c136213d4618b717cda1d6932f707de1c7b3fd6c Author: Paul Floyd <pj...@wa...> Date: Wed Mar 3 08:53:51 2021 +0100 Keep on churning. Without #define _XOPEN_SOURCE macports clang 9.0.1 on OSX 10.7.5 was giving me In file included from swapcontext.c:12: /usr/include/ucontext.h:43:2: error: The deprecated ucontext routines require _XOPEN_SOURCE to be defined ^ swapcontext. So I added #define _XOPEN_SOURCE But that gives, on Solaris 11.3 In file included from /usr/include/limits.h:12:0, from /usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11/4.8.2/include-fixed/limits.h:168, from /usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11/4.8.2/include-fixed/syslimits.h:7, from /usr/gcc/4.8/lib/gcc/i386-pc-solaris2.11/4.8.2/include-fixed/limits.h:34, from swapcontext.c:7: /usr/include/sys/feature_tests.h:354:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications" #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \ ^ So make the #define _XOPEN_SOURCE conditional on darwin. Diff: --- drd/tests/swapcontext.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drd/tests/swapcontext.c b/drd/tests/swapcontext.c index cf600d4933..622c70bc55 100644 --- a/drd/tests/swapcontext.c +++ b/drd/tests/swapcontext.c @@ -1,7 +1,11 @@ /* See also https://bugs.kde.org/show_bug.cgi?id=432381. */ #define _GNU_SOURCE + +#include "../../config.h" +#if defined(VGO_darwin) #define _XOPEN_SOURCE +#endif #include <assert.h> #include <limits.h> |