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: Peter B. <be...@vn...> - 2013-07-01 20:58:21
|
> Am 29.06.2013 01:06, schrieb Eliot Moss: > > 2. At least on x86 and maybe on PPC some status bits indicating failure > and its cause need to be set appropriately when going to the failure path. That is true for PPC too. On Mon, 2013-07-01 at 19:25 +0200, Josef Weidendorfer wrote: > I would assume that there always is a flag for something like "resource > overflow"? In the hope that the failure path does not retry the same > transaction again. On PPC, we have a bit in the TEXASR register that says whether the transaction failure is persistent. If it is persistent, the failure code should not retry the hardware transaction. Peter |
|
From: Peter B. <be...@vn...> - 2013-07-01 20:06:41
|
FYI, I'm the IBM guy adding the GCC HTM support for Power.
Carl has asked me questions wrt valgrind support for HTM, so
I thought I would subscribe to this mailing list to participate
in the conversation.
First off, I'd like to respond to Julian's initial post, but since
that occurred before I joined the mailing list, I'll have to reply
to his post here.
Julian, I agree your (1) proposal is a good and easy starting point,
since valgrind will have to be able to handle the error code path
anyway. However, I think valgrind *will* have to implement something
along the lines of (2) sometime. Implementing (1) now will give us
time to come up with a design for (2) while allowing people to start
executing HTM programs now.
On Mon, 2013-07-01 at 09:28 -0700, Carl E. Love wrote:
> On Fri, 2013-06-28 at 22:16 +0200, Julian Seward wrote:
> > Hi Carl,
> >
> > > would work or not work in Valgrind for the power instructions. Anyway,
> > > any input on the specifics of how I push the simulated execution
> > > directly to the failure path would be helpful. Thanks.
> >
> > I don't know the specifics of the Power instructions, so I can't answer
> > that directly. But I can tell you what the idea was for the Intel
> > instructions -- maybe that would help.
> >
> > (IIRC) the Intel instructions are
> >
> > XBEGIN %reg -- begin a transaction.
> > -- %reg holds the failure-path address
> >
> > XEND -- finish the most recently XBEGIN'd transaction
> >
> > So the idea is very simple: translate XBEGIN %reg as if it was
> > simply a jump to (the code address in) %reg. Does that help?
On Power, a tbegin. instruction sets cr0 to show success or failure
at entering transactional state and updates two new SPR registers:
Transaction EXception And Summary Register (TEXASR):
This register is normally used by failure handlers for
determining why a transaction failed, but it also holds
information about the depth of nested transactions we
currently have.
Transaction Failure Handler Address Register (TFHAR):
This register holds the address the hardware will start
executing from upon a transaction failure/abort. It is
initialized by the tbegin. instruction to CIA+4 (in IBM
parlance), which means it contains the address of the
instruction immediately following the tbegin. instruction.
It can be modified by a "mtspr TFHAR,<reg>", but that
should be a fairly rare occurrence. Similar to x86's
common usage, where the xbegin's %reg is set to the
address following the xbegin.
There is one more HTM SPR register:
Transaction Failure Instruction Address Register (TFIAR):
This register holds the address of the instruction
that caused the transaction failure (when possible).
On Power, to implement (1), we just need to have the tbegin. instruction
return failure by setting cr0 to 0b0010 (ie, 0x2), set the TFHAR to
CIA+4 and then begin executing at the address in the TFHAR.
We'll need to choose a reason why the transaction failed. so we can
initialize the TEXASR and TFIAR for use in the failure handler code.
I highly suggest setting the PERSISTENT flag in the TEXASR, since that
is a hint to the failure handler that this failure is not likely to
go away and retrying the transaction will likely fail. Normally
failure handlers will not retry a hardware transaction if the failure
is marked persistent. A possible failure we could use is that we
hit a resource limit on the number of allowable nested transactions
(heh, one is one too many :).
For the other Power htm instructions, they basically just act as nops
when we're in non-transactional state, so implementing them for (1)
should be straightforward, since we're always in non-transactional
state.
> From what I understand of the power implementation (I have some
> questions for the IBM compiler people) is that the instruction following
> the tbegin will be a branch instruction with the address of the failure
> path. So I guess we could do something similar.
Normally, that is the case, but it doesn't have to immediately follow
the tbegin. ... and it may not even exist, depending on the code we
compiled, so you cannot rely on it being there. That also doesn't
cover the case where the user updates the TFHAR with an address,
so on failure, we don't even branch to the instruction following
the tbegin., but rather to the new address the user stuffed into
the TFHAR.
> However I have some
> concerns. One concern is, what guarantee do we have that the outcome of
> the failure path would be functionally equivalent to the transactional
> path?
There is no guarantee they are functionally equivalent. That can be
due to stupid or untested buggy code or for valid reasons, like a
real hardware transaction shouldn't fail for some specific transactions
and so the programmer omitted the failure handler. Either way, for
(1), I don't think we should sweat it too much, since the former is
totally a user error and they get what they get, while for the latter,
there's nothing we can do until we have (2) working.
> Seems like we are at
> the mercy of whatever the programmer chooses to do in the case of a
> failure. I need to chat with our compiler people about that question.
> I guess in theory the programmer could chose throw up his hands and just
> call exit(1) if the transaction failed. In that case, Valgrind would
> never be able to reproduce a successful run of the program on real
> hardware where there was no TM issues during the run.
Correct, we are at the mercy of whatever the programmer decides to
do when a transaction fails, but if they decide to throw their hands
up in the event of errors, well... that's stupid, but that's their
business. Note that there's nothing special here wrt valgrind that
doesn't also apply to real htm hardware failing for some reason.
The only caveat are the special transactions that normally would never
fail on real hardware, but that will be covered if/when Julian's (2)
proposal is implemented.
As for Julian's (2) proposal, I haven't had time enough to think about
possible solutions, and whether we could (or even should?) possibly rely
on the underlying HTM hardware to help us. I am eager to hear other
people ideas though, if they have them.
Peter
|
|
From: Josef W. <Jos...@gm...> - 2013-07-01 17:25:39
|
Am 29.06.2013 01:06, schrieb Eliot Moss: > Two quick comments: > > 1. *Some* PPC txns are expected to complete if tried repeatedly, and thus will not have a failure path. Hmm. If such transactions are ensured to fall into one SB translation, we could add a flag "execute this translation only in thread-serializing mode", and we can remove the transaction instructions, as it will always succeed. If larger transactions are expected to always succeed after some number of retries, I do not see an easy solution, as any kind of locking (and above serialization will use locks) may result in deadlocks. > 2. At least on x86 and maybe on PPC some status bits indicating failure and its cause need to be set appropriately when going to the failure path. I would assume that there always is a flag for something like "resource overflow"? In the hope that the failure path does not retry the same transaction again. Josef > > Regards - Eliot Moss > Sent via BlackBerry > > -----Original Message----- > From: "Carl E. Love" <ce...@li...> > Date: Fri, 28 Jun 2013 15:37:52 > To: Julian Seward<js...@ac...> > Cc: <val...@li...> > Subject: Re: [Valgrind-developers] Transactional memory implementation input > > On Fri, 2013-06-28 at 22:16 +0200, Julian Seward wrote: >> Hi Carl, >> >>> would work or not work in Valgrind for the power instructions. Anyway, >>> any input on the specifics of how I push the simulated execution >>> directly to the failure path would be helpful. Thanks. >> >> I don't know the specifics of the Power instructions, so I can't answer >> that directly. But I can tell you what the idea was for the Intel >> instructions -- maybe that would help. >> >> (IIRC) the Intel instructions are >> >> XBEGIN %reg -- begin a transaction. >> -- %reg holds the failure-path address >> >> XEND -- finish the most recently XBEGIN'd transaction >> >> So the idea is very simple: translate XBEGIN %reg as if it was >> simply a jump to (the code address in) %reg. Does that help? > > So basically you will unconditionally take the failure path which > presumably is the code to handle the transaction in a non-transactional > way, i.e. to obtain the necessary lock do the operations and then > release the lock. > >>From what I understand of the power implementation (I have some > questions for the IBM compiler people) is that the instruction following > the tbegin will be a branch instruction with the address of the failure > path. So I guess we could do something similar. However I have some > concerns. One concern is, what guarantee do we have that the outcome of > the failure path would be functionally equivalent to the transactional > path? Specifically, did the programmer do the same operations under the > appropriate data lock to guarantee the code sequence is executed > atomically and thus generated the same result?. Seems like we are at > the mercy of whatever the programmer chooses to do in the case of a > failure. I need to chat with our compiler people about that question. > I guess in theory the programmer could chose throw up his hands and just > call exit(1) if the transaction failed. In that case, Valgrind would > never be able to reproduce a successful run of the program on real > hardware where there was no TM issues during the run. Maybe I am still > missing a lot here. Like I said, I am just starting to dive into this > and understand all the issues and ramifications. > >> >> 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 > ------------------------------------------------------------------------------ > 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 > |
|
From: Carl E. L. <ce...@li...> - 2013-07-01 16:28:45
|
Repost, I sent the following message but I didn't see it on the email list. Not sure if it got lost. My apologies if this is a repeat. On Fri, 2013-06-28 at 22:16 +0200, Julian Seward wrote: > Hi Carl, > > > would work or not work in Valgrind for the power instructions. Anyway, > > any input on the specifics of how I push the simulated execution > > directly to the failure path would be helpful. Thanks. > > I don't know the specifics of the Power instructions, so I can't answer > that directly. But I can tell you what the idea was for the Intel > instructions -- maybe that would help. > > (IIRC) the Intel instructions are > > XBEGIN %reg -- begin a transaction. > -- %reg holds the failure-path address > > XEND -- finish the most recently XBEGIN'd transaction > > So the idea is very simple: translate XBEGIN %reg as if it was > simply a jump to (the code address in) %reg. Does that help? So basically you will unconditionally take the failure path which presumably is the code to handle the transaction in a non-transactional way, i.e. to obtain the necessary lock do the operations and then release the lock. >From what I understand of the power implementation (I have some questions for the IBM compiler people) is that the instruction following the tbegin will be a branch instruction with the address of the failure path. So I guess we could do something similar. However I have some concerns. One concern is, what guarantee do we have that the outcome of the failure path would be functionally equivalent to the transactional path? Specifically, did the programmer do the same operations under the appropriate data lock to guarantee the code sequence is executed atomically and thus generated the same result?. Seems like we are at the mercy of whatever the programmer chooses to do in the case of a failure. I need to chat with our compiler people about that question. I guess in theory the programmer could chose throw up his hands and just call exit(1) if the transaction failed. In that case, Valgrind would never be able to reproduce a successful run of the program on real hardware where there was no TM issues during the run. Maybe I am still missing a lot here. Like I said, I am just starting to dive into this and understand all the issues and ramifications. > > J > |
|
From: Philippe W. <phi...@sk...> - 2013-07-01 03:32:44
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) GDB: GNU gdb (GDB) Fedora (7.5.1-37.fc18) Assembler: GNU assembler version 2.23.51.0.1-7.fc18 20120806 C library: GNU C Library stable release version 2.16 uname -mrs: Linux 3.7.2-204.fc18.ppc64 ppc64 Vendor version: Fedora release 18 (Spherical Cow) Nightly build on gcc110 ( Fedora release 18 (Spherical Cow), ppc64 ) Started at 2013-06-30 20:00:09 PDT Ended at 2013-06-30 20:32:17 PDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 557 tests, 31 stderr failures, 3 stdout failures, 0 stderrB failures, 0 stdoutB failures, 2 post failures == memcheck/tests/linux/getregset (stdout) memcheck/tests/linux/getregset (stderr) memcheck/tests/ppc64/power_ISA2_05 (stdout) memcheck/tests/supp_unknown (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stdout) memcheck/tests/wrap8 (stderr) massif/tests/big-alloc (post) massif/tests/deep-D (post) helgrind/tests/annotate_rwlock (stderr) helgrind/tests/free_is_write (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/locked_vs_unlocked1_fwd (stderr) helgrind/tests/locked_vs_unlocked1_rev (stderr) helgrind/tests/locked_vs_unlocked2 (stderr) helgrind/tests/locked_vs_unlocked3 (stderr) helgrind/tests/pth_barrier1 (stderr) helgrind/tests/pth_barrier2 (stderr) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/pth_destroy_cond (stderr) helgrind/tests/rwlock_race (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <to...@co...> - 2013-07-01 03:19:57
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) GDB: Assembler: GNU assembler version 2.18.50.0.6-2 20080403 C library: GNU C Library stable release version 2.8 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 9 (Sulphur) Nightly build on bristol ( x86_64, Fedora 9 ) Started at 2013-07-01 03:51:58 BST Ended at 2013-07-01 04:19:26 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 632 tests, 1 stderr failure, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/amd64/insn-pcmpistri (stderr) none/tests/amd64/sse4-64 (stdout) |
|
From: Tom H. <to...@co...> - 2013-07-01 03:09:03
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2) GDB: Assembler: GNU assembler version 2.19.51.0.14-3.fc11 20090722 C library: GNU C Library stable release version 2.10.2 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 11 (Leonidas) Nightly build on bristol ( x86_64, Fedora 11 ) Started at 2013-07-01 03:41:27 BST Ended at 2013-07-01 04:08:43 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 634 tests, 1 stderr failure, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/long_namespace_xml (stderr) none/tests/amd64/sse4-64 (stdout) |
|
From: Tom H. <to...@co...> - 2013-07-01 03:01:47
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2) GDB: Assembler: GNU assembler version 2.20.51.0.2-20.fc13 20091009 C library: GNU C Library stable release version 2.12.2 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 13 (Goddard) Nightly build on bristol ( x86_64, Fedora 13 ) Started at 2013-07-01 03:32:13 BST Ended at 2013-07-01 04:01:35 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 634 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/pth_barrier3 (stderr) |
|
From: Tom H. <to...@co...> - 2013-07-01 02:55:15
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) GDB: GNU gdb (GDB) Fedora (7.2-52.fc14) Assembler: GNU assembler version 2.20.51.0.7-8.fc14 20100318 C library: GNU C Library stable release version 2.13 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 14 (Laughlin) Nightly build on bristol ( x86_64, Fedora 14 ) Started at 2013-07-01 03:22:31 BST Ended at 2013-07-01 03:54:52 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 653 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) |
|
From: Tom H. <to...@co...> - 2013-07-01 02:45:12
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) GDB: GNU gdb (GDB) Fedora (7.3.1-48.fc15) Assembler: GNU assembler version 2.21.51.0.6-6.fc15 20110118 C library: GNU C Library stable release version 2.14.1 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 15 (Lovelock) Nightly build on bristol ( x86_64, Fedora 15 ) Started at 2013-07-01 03:13:41 BST Ended at 2013-07-01 03:44:50 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 655 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) |
|
From: Tom H. <to...@co...> - 2013-07-01 02:34:54
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) GDB: GNU gdb (GDB) Fedora (7.3.50.20110722-16.fc16) Assembler: GNU assembler version 2.21.53.0.1-6.fc16 20110716 C library: GNU C Library development release version 2.14.90 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 16 (Verne) Nightly build on bristol ( x86_64, Fedora 16 ) Started at 2013-07-01 03:02:43 BST Ended at 2013-07-01 03:34:28 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 655 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) |
|
From: Tom H. <to...@co...> - 2013-07-01 02:23:29
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2) GDB: GNU gdb (GDB) Fedora (7.4.50.20120120-54.fc17) Assembler: GNU assembler version 2.22.52.0.1-10.fc17 20120131 C library: GNU C Library stable release version 2.15 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 17 (Beefy Miracle) Nightly build on bristol ( x86_64, Fedora 17 (Beefy Miracle) ) Started at 2013-07-01 02:51:45 BST Ended at 2013-07-01 03:23:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 655 tests, 5 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == gdbserver_tests/mcinfcallRU (stderr) gdbserver_tests/mcinfcallWSRU (stderr) gdbserver_tests/mcmain_pic (stderr) memcheck/tests/origin5-bz2 (stderr) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) |
|
From: Christian B. <bor...@de...> - 2013-07-01 02:17:35
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.6.1 20110908 (Red Hat 4.6.1-9bb4) GDB: GNU gdb (GDB) Fedora (7.5-1bb1.fc15) Assembler: GNU assembler version 2.21.51.0.6-6bb6.fc15 20110118 C library: GNU C Library stable release version 2.14.1 uname -mrs: Linux 3.8.6-60.x.20130412-s390xperformance s390x Vendor version: unknown Nightly build on fedora390 ( Fedora 15 with devel libc/toolchain on z196 (s390x) ) Started at 2013-07-01 03:45:01 CEST Ended at 2013-07-01 04:17:47 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 636 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) |
|
From: Christian B. <bor...@de...> - 2013-07-01 02:15:41
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973] GDB: GNU gdb (GDB) SUSE (7.3-0.6.1) Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.21.1 C library: GNU C Library stable release version 2.11.3 (20110527) uname -mrs: Linux 3.0.74-0.6.10-default s390x Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP2 (s390x) - Kernel %r (%t). Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP1 gcc 4.3.4 on z196 (s390x) ) Started at 2013-07-01 03:45:01 CEST Ended at 2013-07-01 04:15:29 CEST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 635 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == |
|
From: Tom H. <to...@co...> - 2013-07-01 02:13:47
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.7.2 20121109 (Red Hat 4.7.2-8) GDB: GNU gdb (GDB) Fedora (7.5.1-38.fc18) Assembler: GNU assembler version 2.23.51.0.1-6.fc18 20120806 C library: GNU C Library stable release version 2.16 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 18 (Spherical Cow) Nightly build on bristol ( x86_64, Fedora 18 (Spherical Cow) ) Started at 2013-07-01 02:42:04 BST Ended at 2013-07-01 03:13:32 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 655 tests, 2 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) exp-sgcheck/tests/preen_invars (stdout) exp-sgcheck/tests/preen_invars (stderr) |
|
From: Tom H. <to...@co...> - 2013-07-01 02:04:40
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.8.1 20130603 (Red Hat 4.8.1-1) GDB: GNU gdb (GDB) Fedora (7.6-30.fc19) Assembler: GNU assembler version 2.23.52.0.1-9.fc19 20130226 C library: GNU C Library (GNU libc) stable release version 2.17 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 19 (Schrödingerâs Cat) Nightly build on bristol ( x86_64, Fedora 19 (Schrödingerâs Cat) ) Started at 2013-07-01 02:32:43 BST Ended at 2013-07-01 03:04:25 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 655 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/dw4 (stderr) memcheck/tests/origin5-bz2 (stderr) exp-sgcheck/tests/hackedbz2 (stderr) |
|
From: Tom H. <to...@co...> - 2013-07-01 01:49:56
|
valgrind revision: 13438 VEX revision: 2728 C compiler: gcc (GCC) 4.8.1 20130612 (Red Hat 4.8.1-2) GDB: GNU gdb (GDB) Fedora (7.6-32.fc20) Assembler: GNU assembler version 2.23.2 C library: GNU C Library (GNU libc) development release version 2.17.90 uname -mrs: Linux 3.9.5-301.fc19.x86_64 x86_64 Vendor version: Fedora release 20 (Rawhide) Nightly build on bristol ( x86_64, Fedora 20 ) Started at 2013-07-01 02:22:47 BST Ended at 2013-07-01 02:49:33 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 655 tests, 5 stderr failures, 1 stdout failure, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/amd64/insn_basic (stderr) memcheck/tests/dw4 (stderr) memcheck/tests/origin5-bz2 (stderr) none/tests/amd64/insn_basic (stdout) none/tests/amd64/insn_basic (stderr) exp-sgcheck/tests/hackedbz2 (stderr) |