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
(5) |
3
(2) |
4
(8) |
5
(10) |
|
6
(3) |
7
(9) |
8
(7) |
9
(8) |
10
(7) |
11
(4) |
12
(11) |
|
13
(5) |
14
(17) |
15
(6) |
16
(15) |
17
|
18
(3) |
19
(1) |
|
20
(6) |
21
(18) |
22
(5) |
23
(9) |
24
(6) |
25
(3) |
26
(1) |
|
27
(1) |
28
|
29
(8) |
30
(5) |
|
|
|
|
From: Florian K. <fl...@ei...> - 2015-09-12 20:46:48
|
On 12.09.2015 22:10, Mark Wielaard wrote: > On Sat, 2015-09-12 at 20:42 +0200, Florian Krohm wrote: >> On 12.09.2015 17:23, Mark Wielaard wrote: >> >>> All I can offer you at the moment is the unfiltered output: >>> >>> :::::::::::::: >>> memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out >>> :::::::::::::: >>> ==8767== >>> ==8767== Process terminating with default action of signal 4 (SIGILL) >>> ==8767== Illegal opcode at address 0x834D26BC >>> ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) >>> ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) >>> ==8767== by 0x10001D27: test_binary_op (binary.c:461) >>> ==8767== by 0x10000BCB: main (main.c:135) >>> >>> So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. >>> >> >> That would suggest that the injected code is invalid for ppc32. >> Can you rerun with: >> >> Index: memcheck/tests/vbit-test/vbit-test.vgtest >> =================================================================== >> --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) >> +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) >> @@ -1,2 +1,3 @@ >> prog: vbit-test >> vgopts: -q >> +args: -v -v >> >> The .out file should tell which IROp is causing it. > > :::::::::::::: > memcheck/tests/vbit-test/vbit-test.stdout.out > :::::::::::::: .... > Testing operator Iop_DivU32E > Ah yes.. In host_ppc_isel.c around line 1538 a PPCInstr_Div with extended == 1 is created for tat IROp. Then in host_ppc_defs.c around line 4082 a divweu is generated for that. That seems to be an insn that is only available for power7 and newer. I do not know that for sure but http://www-01.ibm.com/support/knowledgecenter/SSGH4D_14.1.0/com.ibm.xlf141.aix.doc/language_ref/divwe.html says so for divwe (which is for signed extended division). I'd say, this is a bug in the powerpc port. Carl, what do you think? Florian |
|
From: Mark W. <mj...@re...> - 2015-09-12 20:10:17
|
On Sat, 2015-09-12 at 20:42 +0200, Florian Krohm wrote: > On 12.09.2015 17:23, Mark Wielaard wrote: > > > All I can offer you at the moment is the unfiltered output: > > > > :::::::::::::: > > memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out > > :::::::::::::: > > ==8767== > > ==8767== Process terminating with default action of signal 4 (SIGILL) > > ==8767== Illegal opcode at address 0x834D26BC > > ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) > > ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) > > ==8767== by 0x10001D27: test_binary_op (binary.c:461) > > ==8767== by 0x10000BCB: main (main.c:135) > > > > So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. > > > > That would suggest that the injected code is invalid for ppc32. > Can you rerun with: > > Index: memcheck/tests/vbit-test/vbit-test.vgtest > =================================================================== > --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) > +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) > @@ -1,2 +1,3 @@ > prog: vbit-test > vgopts: -q > +args: -v -v > > The .out file should tell which IROp is causing it. :::::::::::::: memcheck/tests/vbit-test/vbit-test.stdout.out :::::::::::::: Testing operator Iop_Add8 Testing operator Iop_Add16 Testing operator Iop_Add32 Testing operator Iop_Add64 Testing operator Iop_Sub8 Testing operator Iop_Sub32 Testing operator Iop_Mul32 Testing operator Iop_Or8 Testing operator Iop_Or16 Testing operator Iop_Or32 Testing operator Iop_Or64 Testing operator Iop_And8 Testing operator Iop_And16 Testing operator Iop_And32 Testing operator Iop_And64 Testing operator Iop_Xor8 Testing operator Iop_Xor16 Testing operator Iop_Xor32 Testing operator Iop_Xor64 Testing operator Iop_Shl8 Testing operator Iop_Shl16 Testing operator Iop_Shl32 Testing operator Iop_Shr32 Testing operator Iop_Sar32 Testing operator Iop_CmpEQ32 Testing operator Iop_CmpNE32 Testing operator Iop_Not8 Testing operator Iop_Not16 Testing operator Iop_Not32 Testing operator Iop_Not64 Testing operator Iop_MullS32 Testing operator Iop_MullU32 Testing operator Iop_Clz32 Testing operator Iop_CmpLT32S Testing operator Iop_CmpLE32S Testing operator Iop_CmpLT32U Testing operator Iop_CmpLE32U Testing operator Iop_CmpwNEZ32 Testing operator Iop_CmpwNEZ64 Testing operator Iop_CmpORD32U Testing operator Iop_CmpORD32S Testing operator Iop_DivU32 Testing operator Iop_DivS32 Testing operator Iop_DivU32E |
|
From: Florian K. <fl...@ei...> - 2015-09-12 19:37:28
|
On 11.09.2015 17:06, Mark Wielaard wrote:
> arm, kernel-4.1.6, glibc-2.22.90, gcc-5.1.1, gdb-7.10, binutils-2.25.1
> arm64 kernel-4.1.5, glibc-2.22, gcc-5.1.1, gdb-7.10, binutils-2.25
Ah, nice.. gcc-5.1.1.. so we can flush out format signedness issues on
arm*
When you get a chance, can you rerun (just make) with:
Index: configure.ac
===================================================================
--- configure.ac (revision 15648)
+++ configure.ac (working copy)
@@ -1913,7 +1913,7 @@
AC_GCC_WARNING_SUBST([format], [FLAG_W_FORMAT])
# Disabled for now until all platforms are clean
format_checking_enabled=no
-#format_checking_enabled=yes
+format_checking_enabled=yes
if test "$format_checking_enabled" = "yes"; then
AC_GCC_WARNING_SUBST([format-signedness], [FLAG_W_FORMAT_SIGNEDNESS])
else
and send me the warnings?
Thanks,
Florian
|
|
From: Florian K. <fl...@ei...> - 2015-09-12 19:26:03
|
On 12.09.2015 15:53, Mark Wielaard wrote: > == 614 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 > stdoutB failures, 0 post failures == > memcheck/tests/bug340392 (stderr) > > So that means it is just that --expensive-definedness-checks=yes doesn't > help on ppc64 for this testcase. > Known issue: https://bugs.kde.org/show_bug.cgi?id=352364 Florian |
|
From: Florian K. <fl...@ei...> - 2015-09-12 18:50:30
|
Carl,
while looking at the vbit-test failure on ppc32 I noticed that in
guest_ppc_toIR.c all dis_dfp_XYZZY functions are guarded by
if (!allow_DFP) goto decode_noDFP
except the two below. An oversight ?
Florian
Index: VEX/priv/guest_ppc_toIR.c
===================================================================
--- VEX/priv/guest_ppc_toIR.c (revision 3187)
+++ VEX/priv/guest_ppc_toIR.c (working copy)
@@ -19172,6 +19172,7 @@
case 0x322: // POWER 7 inst, dcffix - DFP convert from fixed
if (!allow_VX)
goto decode_failure;
+ if (!allow_DFP) goto decode_noDFP;
if (dis_dfp_fmt_conv( theInstr ))
goto decode_success;
goto decode_failure;
@@ -19598,6 +19599,7 @@
goto decode_success;
goto decode_failure;
case 0xA2: // dtstexq - DFP Test exponent Quad
+ if (!allow_DFP) goto decode_noDFP;
if (dis_dfp_exponent_test( theInstr ) )
goto decode_success;
goto decode_failure;
|
|
From: Florian K. <fl...@ei...> - 2015-09-12 18:42:57
|
On 12.09.2015 17:23, Mark Wielaard wrote: > All I can offer you at the moment is the unfiltered output: > > :::::::::::::: > memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out > :::::::::::::: > ==8767== > ==8767== Process terminating with default action of signal 4 (SIGILL) > ==8767== Illegal opcode at address 0x834D26BC > ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) > ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) > ==8767== by 0x10001D27: test_binary_op (binary.c:461) > ==8767== by 0x10000BCB: main (main.c:135) > > So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. > That would suggest that the injected code is invalid for ppc32. Can you rerun with: Index: memcheck/tests/vbit-test/vbit-test.vgtest =================================================================== --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) @@ -1,2 +1,3 @@ prog: vbit-test vgopts: -q +args: -v -v The .out file should tell which IROp is causing it. Florian |
|
From: Mark W. <mj...@re...> - 2015-09-12 15:23:50
|
On Sat, 2015-09-12 at 10:06 +0200, Florian Krohm wrote: > On 11.09.2015 17:06, Mark Wielaard wrote: > > > > ppc, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2 > > == 587 tests, 7 stderr failures, 0 stdout failures, 0 stderrB failures, > > 0 stdoutB failures, 1 post failure == > > memcheck/tests/leak-segv-jmp (stderr) > > memcheck/tests/linux/stack_changes (stderr) > > memcheck/tests/vbit-test/vbit-test (stderr) > > I'd be interested in the vbit-test failure. This should not happen. Sadly I don't have interactive access to the machine that produces this result and I cannot replicate on a (different) ppc64 setup. Even when running everything under "setarch ppc32" the vbit test passes just fine. All I can offer you at the moment is the unfiltered output: :::::::::::::: memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out :::::::::::::: ==8767== ==8767== Process terminating with default action of signal 4 (SIGILL) ==8767== Illegal opcode at address 0x834D26BC ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) ==8767== by 0x10001D27: test_binary_op (binary.c:461) ==8767== by 0x10000BCB: main (main.c:135) So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. |
|
From: Mark W. <mj...@re...> - 2015-09-12 14:37:34
|
On Fri, 2015-09-11 at 21:05 +0200, Mark Wielaard wrote:
> ppc64, kernel-2.6.32, gcc-4.8.3, glibc-2.17, binutils-2.23.52.0.1,
> gdb-7.6.1
> == 620 tests, 38 stderr failures, 34 stdout failures, 1 stderrB
> failure, 1 stdoutB failure, 0 post failures ==
> gdbserver_tests/hginfo (stderrB)
> gdbserver_tests/hgtls (stdoutB)
> memcheck/tests/bug340392 (stderr)
> memcheck/tests/leak_cpp_interior (stderr)
> memcheck/tests/ppc32/power_ISA2_05 (stdout)
> memcheck/tests/ppc32/power_ISA2_05 (stderr)
> none/tests/allexec32 (stdout)
> none/tests/allexec32 (stderr)
> none/tests/allexec64 (stdout)
> none/tests/allexec64 (stderr)
> none/tests/ppc32/bug129390-ppc32 (stdout)
> none/tests/ppc32/bug129390-ppc32 (stderr)
> none/tests/ppc32/bug139050-ppc32 (stdout)
> none/tests/ppc32/bug139050-ppc32 (stderr)
> none/tests/ppc32/data-cache-instructions (stdout)
> none/tests/ppc32/data-cache-instructions (stderr)
> none/tests/ppc32/jm-fp (stdout)
> none/tests/ppc32/jm-fp (stderr)
> none/tests/ppc32/jm-int (stdout)
> none/tests/ppc32/jm-int (stderr)
> none/tests/ppc32/jm-misc (stdout)
> none/tests/ppc32/jm-misc (stderr)
> none/tests/ppc32/jm-vmx (stdout)
> none/tests/ppc32/jm-vmx (stderr)
> none/tests/ppc32/ldst_multiple (stdout)
> none/tests/ppc32/ldst_multiple (stderr)
> none/tests/ppc32/ldstrev (stdout)
> none/tests/ppc32/ldstrev (stderr)
> none/tests/ppc32/lsw (stdout)
> none/tests/ppc32/lsw (stderr)
> none/tests/ppc32/mcrfs (stdout)
> none/tests/ppc32/mcrfs (stderr)
> none/tests/ppc32/mftocrf (stdout)
> none/tests/ppc32/mftocrf (stderr)
> none/tests/ppc32/power5+_round (stdout)
> none/tests/ppc32/power5+_round (stderr)
> none/tests/ppc32/power6_bcmp (stderr)
> none/tests/ppc32/round (stdout)
> none/tests/ppc32/round (stderr)
> none/tests/ppc32/test_dfp1 (stdout)
> none/tests/ppc32/test_dfp1 (stderr)
> none/tests/ppc32/test_dfp2 (stdout)
> none/tests/ppc32/test_dfp2 (stderr)
> none/tests/ppc32/test_dfp3 (stdout)
> none/tests/ppc32/test_dfp3 (stderr)
> none/tests/ppc32/test_dfp4 (stdout)
> none/tests/ppc32/test_dfp4 (stderr)
> none/tests/ppc32/test_dfp5 (stdout)
> none/tests/ppc32/test_dfp5 (stderr)
> none/tests/ppc32/test_fx (stdout)
> none/tests/ppc32/test_fx (stderr)
> none/tests/ppc32/test_gx (stdout)
> none/tests/ppc32/test_gx (stderr)
> none/tests/ppc32/test_isa_2_06_part1 (stdout)
> none/tests/ppc32/test_isa_2_06_part1 (stderr)
> none/tests/ppc32/test_isa_2_06_part2 (stdout)
> none/tests/ppc32/test_isa_2_06_part2 (stderr)
> none/tests/ppc32/test_isa_2_06_part3 (stdout)
> none/tests/ppc32/test_isa_2_06_part3 (stderr)
> none/tests/ppc32/testVMX (stdout)
> none/tests/ppc32/testVMX (stderr)
> none/tests/ppc32/tw (stdout)
> none/tests/ppc32/tw (stderr)
> none/tests/ppc32/twi (stdout)
> none/tests/ppc32/twi (stderr)
> none/tests/ppc32/xlc_dbl_u32 (stdout)
> none/tests/ppc32/xlc_dbl_u32 (stderr)
> none/tests/ppc64/jm-fp (stdout)
> none/tests/ppc64/jm-fp (stderr)
> none/tests/ppc64/jm-int (stdout)
> none/tests/ppc64/jm-int (stderr)
> none/tests/ppc64/jm-vmx (stdout)
> none/tests/ppc64/jm-vmx (stderr)
> helgrind/tests/tc06_two_races_xml (stderr)
>
> [The large number of ppc32 failures seem to come from the usage of
> a 64bit only instruction in the 32bit ld.so index function.]
I tried with a slightly newer glibc version and couldn't replicate the
ppc32 failures. The results now look like:
== 634 tests, 6 stderr failures, 3 stdout failures, 0 stderrB failures,
1 stdoutB failure, 0 post failures ==
gdbserver_tests/hgtls (stdoutB)
memcheck/tests/bug340392 (stderr)
memcheck/tests/leak_cpp_interior (stderr)
none/tests/ppc64/jm-fp (stdout)
none/tests/ppc64/jm-fp (stderr)
none/tests/ppc64/jm-int (stdout)
none/tests/ppc64/jm-int (stderr)
none/tests/ppc64/jm-vmx (stdout)
none/tests/ppc64/jm-vmx (stderr)
helgrind/tests/tc06_two_races_xml (stderr)
The jm-fp, jm-int and jm-vmx tests all fail because they crash (also
when running natively) inside this code:
Program received signal SIGSEGV, Segmentation fault.
init_function (func_buf=0x3fffb7d70000,
p_func_F=@0x1001e328: 0x10000bd4 <.test_lfs>) at jm-insns.c:4875
4875 descr[0] = (uint64_t)&func_buf[0];
4868 /* p_func points to a function descriptor, the first word of which
4869 points to the real code. Copy the code itself but not the
4870 descriptor, and just swizzle the descriptor's entry pointer. */
4871 uint64_t* descr = (uint64_t*)p_func;
4872 uint32_t* entry = (uint32_t*)(descr[0]);
4873 func_buf[0] = entry[0];
4874 func_buf[1] = entry[1];
4875 descr[0] = (uint64_t)&func_buf[0];
4876 return (test_func_t)descr;
4877 #endif // #ifndef __powerpc64__
|
|
From: Mark W. <mj...@re...> - 2015-09-12 13:53:46
|
On Fri, 2015-09-11 at 17:06 +0200, Mark Wielaard wrote: > ppc64, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, > binutils-2.20.51.0.2 > == No results == > > [vgdb tests hang. I doubt it is a valgrind issue, I'll try rerunning > without the gdb_server tests.] I tried to replicate this and failed to reproduce the hang. The result is actually near perfect for this setup: == 614 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/bug340392 (stderr) So that means it is just that --expensive-definedness-checks=yes doesn't help on ppc64 for this testcase. |
|
From: Florian K. <fl...@ei...> - 2015-09-12 08:07:14
|
On 11.09.2015 17:06, Mark Wielaard wrote:
>
> ppc, kernel-2.6.32, glibc-2.12, gcc-4.4.7, gdb-7.2, binutils-2.20.51.0.2
> == 587 tests, 7 stderr failures, 0 stdout failures, 0 stderrB failures,
> 0 stdoutB failures, 1 post failure ==
> memcheck/tests/leak-segv-jmp (stderr)
> memcheck/tests/linux/stack_changes (stderr)
> memcheck/tests/vbit-test/vbit-test (stderr)
I'd be interested in the vbit-test failure. This should not happen.
Florian
|
|
From: <sv...@va...> - 2015-09-12 06:12:34
|
Author: rhyskidd
Date: Sat Sep 12 07:12:27 2015
New Revision: 15649
Log:
Re-enable formerly hanging regression test on OS X.
Related to bz#350359 and vex: r3184.
On OS X 10.10
Before:
== 595 tests, 215 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 30 post failures ==
After:
== 596 tests, 215 stderr failures, 10 stdout failures, 0 stderrB failures, 0 stdoutB failures, 30 post failures ==
Modified:
trunk/memcheck/tests/x86/fxsave.vgtest
Modified: trunk/memcheck/tests/x86/fxsave.vgtest
==============================================================================
--- trunk/memcheck/tests/x86/fxsave.vgtest (original)
+++ trunk/memcheck/tests/x86/fxsave.vgtest Sat Sep 12 07:12:27 2015
@@ -1,4 +1,4 @@
prog: fxsave
-prereq: ../../../tests/x86_amd64_features x86-sse && ! ../../../tests/os_test darwin
+prereq: ../../../tests/x86_amd64_features x86-sse
vgopts: -q
args: x
|