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
(16) |
3
(23) |
|
4
(13) |
5
(1) |
6
(1) |
7
(17) |
8
(18) |
9
(14) |
10
(12) |
|
11
|
12
(6) |
13
(19) |
14
(4) |
15
(7) |
16
(30) |
17
(12) |
|
18
(2) |
19
(13) |
20
(3) |
21
(3) |
22
(17) |
23
(16) |
24
(5) |
|
25
(14) |
26
(15) |
27
(4) |
28
(15) |
29
(16) |
30
(16) |
31
(15) |
|
From: Carl E. L. <ce...@li...> - 2013-08-16 22:06:14
|
On Fri, 2013-08-16 at 16:24 +0200, Julian Seward wrote:
> > I have implemented the second proposal for Power. [...]
>
> I'm not sure I understand the details of how TM is presented in the Power
> instruction set and architectural state. It seems broadly similar to the
> Intel scheme, though, in which there are two basic primitives:
>
> T_BEGIN, which takes the failure handler address as a parameter
> T_END
>
> T_BEGIN starts a new transaction. T_END ends it and releases any resources
> associated with it. If the transaction fails for any reason, the processor
> jumps to the handler address specified by T_BEGIN. Typically, if the
> transaction fails, some registers will be set, indicating the reason, before
> jumping to the failure handler; although that is secondary to this
> discussion.
On Power, the compiler generates the T_BEGIN instruction followed by an
conditional branch instruction. The result of executing the T_BEGIN
instruction is to set the condition code register. If the T_BEGIN
succeeds, then the subsequent branch instruction will cause the control
flow to follow the successful code path. Otherwise, the branch causes
execution to follow the failure path. The code sequence is essentially
as follows:
tbegin.
beq <failure path>
// success path
Note, the are no restrictions preventing the compiler from putting
additional instructions between the tbegin and the beq in the above code
sequence. We do not tell the CPU where to go on failure as is done in
the Intel T_BEGIN.
Power has three registers for use by the TM instructions. Here is
Peter's description of the registers.
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.
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 Instruction Address Register (TFIAR):
This register holds the address of the instruction
that caused the transaction failure (when possible).
>
> My vague implementation sketch for this second proposal was:
>
> * when the guest CPU guest arrives at the T_BEGIN(guest-fail-handler)
> instruction, call a dirty helper function which:
>
> - adds guest-fail-handler to a stack of handler addresses
> for the current thread
Power places the address of the error branch code into the TFHA. The
nesting level for the TM is updated in the TEXASR register. For now,
lets not consider nested TMs.
>
> - (on the the host) does T_BEGIN(host-fail-handler). Note that
> host-fail-handler is part of the valgrind C code and is
> is definitely != guest-fail-handler
In my implementation, the host executes the tbegin. I didn't do
anything to set or change the host TFIAR register. I capture the value
from the condition code register and write that into the guest machine's
condition code register. I also capture the value of the register
(TEXASR) containing the reason for the failure and put it in the guest
TEXASR. Thus the guest code control flow will take either the success or
failure path based on the updated guest condition code register which
contains the result of executing the T_BEGIN on the host.
>
> * the dirty helper returns (to JITted code), and continues. This
> is (of course) part of the transaction on the host. The guest CPU
> therefore continues with the instructions that are part of the
> (guest) transaction.
The code that I have as part of the tbegin implementation copies the
condition code register and TEXASR value from the host to the guest
machine registers I guess is what you would refer to as the dirty
helper. I my case, the code is not in an explicit function but could be
put into an explicit dirty helper function. The code I am talking about
is:
+ /* The TEXASR is returned from the TBEGIN instruction in the
upper
+ * 64-bits, the CC register is returned in the lowest 32-bits.
+ */
+ assign( rDst, unop( Iop_TBEGIN, mkU32( R_field ) ) );
+
+ assign( texasr, unop( Iop_128HIto64, mkexpr( rDst ) ) );
+ assign( lDst, unop( Iop_128to64, mkexpr( rDst ) ) );
+ assign( CondCode, unop( Iop_64to32, mkexpr( lDst) ) );
+
+ /* Set the CR0 field to indicate the tbegin failed. Then let
+ * the code do the branch to the success/failure path.
+ *
+ * 000 || 0 Transaction initiation successful,
+ * unnested (Transaction state of
+ * Non-transactional prior to tbegin.)
+ * 010 || 0 Transaction initiation successful, nested
+ * (Transaction state of Transactional
+ * prior to tbegin.)
+ * 001 || 0 Transaction initiation unsuccessful,
+ * (Transaction state of Suspended prior
+ * to tbegin.)
+ */
+
+ /* 0x2 takes transactional path */
+ /* 0x0 takes the failure path */
+
+ putGST( PPC_GST_TFIAR, mkU64( guest_CIA_curr_instr) );
+ putGST( PPC_GST_TEXASR, mkexpr( texasr ) );
+ putGST( PPC_GST_TFHAR, mkU64( guest_CIA_curr_instr+4 ) );
+
+ return True;
+
+ break;
>
> * (if the transaction does not fail)
> the guest CPU arrives at T_END. It calls another dirty helper
> function which first does T_END on the host, then pops
> guest-fail-handler off the stack of handler addresses for
> the thread. The transaction is over.
In my implementation the T_END instruction is actually a noop right now.
Looking at it again as I write this response I see this is an error in
my current implementation. I will fix it.
What happens, is the host is executing the guest instructions issued to
the host as well as the instructions from Valgrind. The Host HW detects
the HW can't track all of the instructions being executed. Since I
didn't issue the T_END the TM is bound to fail eventually. The
host HW rolls the state of the registers back to the state at the
tbegin, updates the condition code register to failure, sets the TEXASR
register. Then the return from the host executing the T_BEGIN
effectively happens again but this time the condition code register and
TEXASR are set for failure and we go down the failure path in the guest
code. So, in my implementation, I see that the HW resources were
exceeded and I only see the results of the failure path.
>
> * (if the transaction fails)
> the host CPU will jump to host-fail-handler.
> This behaves similarly to how synchronous signals are currently
> handled:
> basically host-fail-handler must longjmp out of the JITted code, over
> m_dispatch/dispatch-*.S, back into the scheduler, indicating somehow
> that a transaction has failed. The scheduler can then fix up the guest
> state, by popping guest-fail-handler off this thread's handler stack,
> setting the guest state program counter to that value, and letting the
> guest CPU resume.
I believe what the hardware does once the failure occurs is that all of
the register and memory changes that occurred between the T_BEGIN and
the failure are erased and we go back to the T_BEGIN instruction
(Program counter again points to the T_BEGIN), update the condition code
register, the TEXASR and the TFIAR and continue executing the code
sequence with the condition code set to failure thus following the TM
failure path as if we had never been down the success path. This is
what I understand of how this works at the hardware level.
>
> What is crucial (and I was unable to determine from your description) is
> that we cannot pass the guest's failure-handling address through to the
> host, since otherwise we will permanently lose control of execution when
> the transaction fails.
>From what I understand of how Power implements this, we have reset the
state of the HW back to the state when the T_BEGIN started executing,
i.e. the program counter is set back to the T_BEGIN. So, we are not
going to lose control of the execution as we never tell the CPU
explicitly where to go on failure.
>
> Whether or not the transactions on the host get nuked due to resource
> constraints is orthogonal to the above proposal. In principle, if the
> host has enough tracking resources, it could succeed.
Yes, it could, assuming I actually do the T_END. I will fix that and
try again.
An alternative implementation suggestion. I believe Valgrind is single
threaded, correct? When we see a T_BEGIN couldn't we just have the
Valgrind scheduler just continue to execute instructions in the same
thread/CPU until the T_END is seen. We would effectively make the
transactional memory thread sequential so there wouldn't be any
conflicts with other threads. The host would not execute any of the TM
instructions. We would then make the Power suspend and abort
instructions noops. The transaction abort and end instructions would
then allow the Valgrind scheduler to go back to scheduling threads/CPUs
normally. Not sure if this is a viable solution for Valgrind or not. I
just don't know enough of the internals.
>
> Note that none of this involves changing the IR, so none of the tools
> have to be aware that transactions are supported.
>From the POWER perspective, all the register/memory updates are erased
so the tools would have no way of knowing.
>
> Does any of the above sync with how you did your Power implementation?
>
> J
>
|
|
From: Milind C. <Mil...@ri...> - 2013-08-16 18:37:49
|
Philippe, >> The callgrind tool maintains the callstack on-the-fly via call-ret, but this callstack maintenance is specialised for callgrind. I noticed that Helgrind shows full call stack of 2 conflicting accesses during a data races. Does it maintain a call path identifier associated with each memory access in a shadow memory? If it does, doesn't Helgrind need to obtain the call stack on each memory access instruction? Does Helgrind also build the stack on-the-fly via call-ret and maintain a dictionary of call paths? On Fri, Aug 16, 2013 at 3:28 AM, Philippe Waroquiers < phi...@sk...> wrote: > On Wed, 2013-08-14 at 08:44 -0700, Milind Chabbi wrote: > > Resending my question. Is this the right mailing list to ask valgrind > > internals question? > Yes. > > > > > > On Tue, Aug 13, 2013 at 12:19 PM, Milind Chabbi > > <Mil...@ri...> wrote: > > Hello, > > > > I am considering using Valgrind for a heavy-weight > > instrumentation > > that would instrument each memory access. > > For detailed information about the access, I want to collect > > the full > > call path of each access. > > Can someone tell me (at the high-level) what call path > > collection > > technique exists in Valgrind ? and give me some details of the > > feature > > such as algorithmic complexity of getting the call stack esp. > > for each > > instruction. Is it done using a stack unwinding technique or > > it is > > built on-the-fly via call-ret instructions? How is a call path > > represented (is it an identifier to a call path object that > > can be > > queried at a later time) ? > A stack trace is obtained by calling VG_(get_StackTrace) > (see pub_tool_stacktrace.h). > For frequent events (e.g. stacktraces of malloc,free,... in memcheck), > there will be a lot of identical stacktraces. These can be maintained > in a "dictionnary of stacktraces". See pub_tool_execontext.h. > So, an execontext corresponds more or less to an > "identifier ... that can be queried at a later time". > > Getting stacktraces is done via unwind technique, so is quite costly. > Doing it for each memory access instruction will be very slow. > > The callgrind tool maintains the callstack on-the-fly via call-ret, > but this callstack maintenance is specialised for callgrind. > It might be an interesting project to generalise this callgrind > callstack maintenance and make it "general" (i.e. part of the > valgrind core framework) rather than tool specific. > > What kind of tool are you thinking to ? > It might maybe easier to extend callgrind, which already captures > memory access related information and callstack. > > Philippe > > > > > > |
|
From: Philippe W. <phi...@sk...> - 2013-08-16 18:24:48
|
On Fri, 2013-08-16 at 11:16 -0700, Milind Chabbi wrote: > Philippe, > > > >> The callgrind tool maintains the callstack on-the-fly via > call-ret, but this callstack maintenance is specialised for callgrind. > > > I noticed that Helgrind shows full call stack of 2 conflicting > accesses during a data races. Does it maintain a call path identifier > associated with each memory access in a shadow memory? If it does, > doesn't Helgrind need to obtain the call stack on each memory access > instruction? Does Helgrind also build the stack on-the-fly via > call-ret and maintain a dictionary of call paths? helgrind does not use call-ret, but uses VG_(get_StackTrace) (limited to 8 frames from what I can see). I do not know if helgrind does that for all memory access or only a subset of the memory access. Philippe |
|
From: <sv...@va...> - 2013-08-16 16:15:48
|
jf 2013-08-16 16:15:37 +0000 (Fri, 16 Aug 2013)
New Revision: 479
Log:
remove redundant file
Removed files:
trunk/base
Deleted: trunk/base (+0 -0)
===================================================================
|
|
From: Maynard J. <may...@us...> - 2013-08-16 15:46:23
|
On 08/16/2013 09:55 AM, Julian Seward wrote: > > Maynard, > > Florian landed a change last night -- r13498/r2742 -- which should fix this. > Pls yell if it's still broken. OK, thanks. I'll be out for a couple weeks as of this afternoon, and so will verify the fix when I return. -Maynard > > J > > On 08/14/2013 02:51 PM, Maynard Johnson wrote: >> On 08/13/2013 03:03 PM, Florian Krohm wrote: >>> On 08/13/2013 09:51 PM, Maynard Johnson wrote: >>>> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: >> Sorry, but I forgot to say yesterday that I was only seeing this error on my Intel Core 2 Duo laptop. The current valgrind from SVN trunk worked OK on my ppc64 box. >> >> I'm at a different work location today and using a Sandybridge laptop (Intel Core i7) -- and oddly, I cannot reproduce the error, using the same JVM. >> >> -Maynard >>>> >>>> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >>>> ==18410== Nulgrind, the minimal Valgrind tool >>>> ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >>>> ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >>>> ==18410== Command: java ThreadLoop 1 >>>> ==18410== >>>> --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >>>> --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 >>>> >>>> valgrind: the 'impossible' happened: >>>> Killed by fatal signal >>>> ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) >>>> ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) >>> >>> I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, >>> the faulting address. Looks as if deepCopyIRExprVec does not handle the >>> special expressions introduced recently. There may be other places. I >>> haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. >>> >>> Florian >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Get 100% visibility into Java/.NET code with AppDynamics Lite! >> It's a free troubleshooting tool designed for production. >> Get down to code-level detail for bottlenecks, with <2% overhead. >> Download for free and get started troubleshooting in minutes. >> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk >> _______________________________________________ >> Valgrind-developers mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-developers >> > |
|
From: Niall D. <ndo...@bl...> - 2013-08-16 15:37:39
|
> > Note that for non-x86/x86 callgrind's optimized callstack generator > > isn't reliable. > Is there a way to differentiate the (at instrumentation time or at > runtime) the instructions which leads to this non reliability. > Then for such instructions, a more reliable but slower technique could be > used > (e.g. unwind information, see below). Josef and Julian will know the answer to this, but essentially the problem is that it is very hard to (quickly) reconstruct what's going on precisely on ARM from just the stack alone. > > There is scope to greatly improve valgrind's callstack generator in > > general if we had an unwind table parser (see -funwind-tables in GCC). > > libunwind has one, but it need libc which makes it unsuitable for > > valgrind. > Not too sure how to understand the above: Valgrind today generates > stacktraces using unwind information, see e.g. in coregrind > pub_core_debuginfo.h, m_stacktrace.c and files in coregrind/m_debuginfo. Correct, though not in callgrind nor cachegrind. It is rather slow and memory hungry though. > > Also, Julian > > has some ARM EXIDX unwind table parser code he can point you at if > > you're interested. > What is the difference between these unwind tables and the dwarf unwind > tables ? ARM EXIDX unwind tables are specified by the ARM ABI for C++ exception unwinds. They are not a dwarf format, though can be (slowly) converted into a subset of dwarf format which is what Julian's code does. A native ARM EXIDX unwind table parser would very significantly improve stack backtrace performance on ARM valgrind, as well as making callgrind and cachegrind actually useful on ARM. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc. |
|
From: Philippe W. <phi...@sk...> - 2013-08-16 15:26:18
|
On Fri, 2013-08-16 at 14:25 +0000, Niall Douglas wrote: > > Getting stacktraces is done via unwind technique, so is quite costly. > > Doing it for each memory access instruction will be very slow. > > > > The callgrind tool maintains the callstack on-the-fly via call-ret, but > this callstack > > maintenance is specialised for callgrind. > > It might be an interesting project to generalise this callgrind callstack > > maintenance and make it "general" (i.e. part of the valgrind core > framework) > > rather than tool specific. > > Note that for non-x86/x86 callgrind's optimized callstack generator isn't > reliable. Is there a way to differentiate the (at instrumentation time or at runtime) the instructions which leads to this non reliability. Then for such instructions, a more reliable but slower technique could be used (e.g. unwind information, see below). > > There is scope to greatly improve valgrind's callstack generator in general > if we had an unwind table parser (see -funwind-tables in GCC). libunwind has > one, but it need libc which makes it unsuitable for valgrind. Not too sure how to understand the above: Valgrind today generates stacktraces using unwind information, see e.g. in coregrind pub_core_debuginfo.h, m_stacktrace.c and files in coregrind/m_debuginfo. > Also, Julian > has some ARM EXIDX unwind table parser code he can point you at if you're > interested. What is the difference between these unwind tables and the dwarf unwind tables ? Philippe |
|
From: <sv...@va...> - 2013-08-16 15:09:52
|
NoMethodError: undefined method `to_a' for "remove phpinfo.php as everything seems to be working\n":String /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:647:in `make_subject' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:594:in `make_header' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:397:in `make_mail' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:309:in `run' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:48:in `run' /usr/local/share/subversion/hook-scripts/commit-email.rb:69:in `<main>' |
|
From: Philippe W. <phi...@sk...> - 2013-08-16 15:06:51
|
On Tue, 2013-08-13 at 13:34 +0400, Alexander Potapenko wrote:
> (+timurrrr)
> For the record, another idea is to perform the leak checking when the
> program is being terminated by an exit() call or right after the
> return from main().
> If I insert VALGRIND_DO_LEAK_CHECK right before "return 0" in the
> above example, no leaks are reported, because the detached threads are
> still live.
> Perhaps we shouldn't shut them down before checking for leaks?
It is better to have only one thread remaining when doing
the leak search to e.g. avoid problems when running
the libc free resource (see valgrind option
--run-libc-freeres=no|yes).
The attached patch solves the problem by having the exiting thread
marking (using VgSrc_ExitProcess) the other threads which must
terminate due to the sys_exit_group syscall.
The exitreason VgSrc_ExitProcess is then used to detect that
the registers of an empty thread still have to be used for leak
search.
Patch has been regression tested on linux x86, amd64 and ppc64.
Assuming the approach in the patch is deemed ok, there are still a few
additional points to cleanup e.g.
the darwin equivalent code should be done
(would be nice to have an access to a darwin system for that)
some obsolete comments about VgSrc_ExitProcess
confirming (or not) that a process can have threads of multiple
thread group, and updating the code accordingly
Philippe
|
|
From: <sv...@va...> - 2013-08-16 15:01:40
|
NoMethodError: undefined method `to_a' for #<String:0x000008094ff9c8> /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:647:in `make_subject' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:594:in `make_header' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:397:in `make_mail' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:309:in `run' /usr/local/lib/ruby/site_ruby/1.9/svn/commit-mailer.rb:48:in `run' /usr/local/share/subversion/hook-scripts/commit-email.rb:69:in `<main>' |
|
From: Julian S. <js...@ac...> - 2013-08-16 14:55:41
|
Maynard, Florian landed a change last night -- r13498/r2742 -- which should fix this. Pls yell if it's still broken. J On 08/14/2013 02:51 PM, Maynard Johnson wrote: > On 08/13/2013 03:03 PM, Florian Krohm wrote: >> On 08/13/2013 09:51 PM, Maynard Johnson wrote: >>> Using an SVN checkout done today, I get the following error when running a test java app under Valgrind: > Sorry, but I forgot to say yesterday that I was only seeing this error on my Intel Core 2 Duo laptop. The current valgrind from SVN trunk worked OK on my ppc64 box. > > I'm at a different work location today and using a Sandybridge laptop (Intel Core i7) -- and oddly, I cannot reproduce the error, using the same JVM. > > -Maynard >>> >>> [maynard@oc3431575272 myJavaStuff]$ valgrind --tool=none java ThreadLoop 1 >>> ==18410== Nulgrind, the minimal Valgrind tool >>> ==18410== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote. >>> ==18410== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info >>> ==18410== Command: java ThreadLoop 1 >>> ==18410== >>> --18410-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting >>> --18410-- si_code=1; Faulting address: 0x11; sp: 0x80277d490 >>> >>> valgrind: the 'impossible' happened: >>> Killed by fatal signal >>> ==18410== at 0x380BF6BB: deepCopyIRExpr (ir_defs.c:2130) >>> ==18410== by 0x380BFB14: deepCopyIRExprVec (ir_defs.c:2093) >> >> I bet that e is IRExprP__BBPTR which is ((IRExpr*)17) which is 0x11, >> the faulting address. Looks as if deepCopyIRExprVec does not handle the >> special expressions introduced recently. There may be other places. I >> haven't checked. Unless you beat me to it I'll look at fixing it tomorrow. >> >> Florian >> >> > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Niall D. <ndo...@bl...> - 2013-08-16 14:41:11
|
> Getting stacktraces is done via unwind technique, so is quite costly. > Doing it for each memory access instruction will be very slow. > > The callgrind tool maintains the callstack on-the-fly via call-ret, but this callstack > maintenance is specialised for callgrind. > It might be an interesting project to generalise this callgrind callstack > maintenance and make it "general" (i.e. part of the valgrind core framework) > rather than tool specific. Note that for non-x86/x86 callgrind's optimized callstack generator isn't reliable. There is scope to greatly improve valgrind's callstack generator in general if we had an unwind table parser (see -funwind-tables in GCC). libunwind has one, but it need libc which makes it unsuitable for valgrind. Also, Julian has some ARM EXIDX unwind table parser code he can point you at if you're interested. As how to start into a callpath collection tool, I'd say an improved callstack generator for valgrind would be an excellent beginning, especially as it would greatly improve all valgrind tooling. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc. |
|
From: Julian S. <js...@ac...> - 2013-08-16 14:29:53
|
On 08/16/2013 12:28 PM, Philippe Waroquiers wrote: > Getting stacktraces is done via unwind technique, so is quite costly. > Doing it for each memory access instruction will be very slow. Yes, it will slow down execution by a factor of several thousand compared to native execution -- I'd guess -- so you'll wind up with something that is unusably slow on anything except the smallest problems. J |
|
From: Julian S. <js...@ac...> - 2013-08-16 14:25:08
|
> I have implemented the second proposal for Power. [...]
I'm not sure I understand the details of how TM is presented in the Power
instruction set and architectural state. It seems broadly similar to the
Intel scheme, though, in which there are two basic primitives:
T_BEGIN, which takes the failure handler address as a parameter
T_END
T_BEGIN starts a new transaction. T_END ends it and releases any resources
associated with it. If the transaction fails for any reason, the processor
jumps to the handler address specified by T_BEGIN. Typically, if the
transaction fails, some registers will be set, indicating the reason, before
jumping to the failure handler; although that is secondary to this
discussion.
My vague implementation sketch for this second proposal was:
* when the guest CPU guest arrives at the T_BEGIN(guest-fail-handler)
instruction, call a dirty helper function which:
- adds guest-fail-handler to a stack of handler addresses
for the current thread
- (on the the host) does T_BEGIN(host-fail-handler). Note that
host-fail-handler is part of the valgrind C code and is
is definitely != guest-fail-handler
* the dirty helper returns (to JITted code), and continues. This
is (of course) part of the transaction on the host. The guest CPU
therefore continues with the instructions that are part of the
(guest) transaction.
* (if the transaction does not fail)
the guest CPU arrives at T_END. It calls another dirty helper
function which first does T_END on the host, then pops
guest-fail-handler off the stack of handler addresses for
the thread. The transaction is over.
* (if the transaction fails)
the host CPU will jump to host-fail-handler.
This behaves similarly to how synchronous signals are currently
handled:
basically host-fail-handler must longjmp out of the JITted code, over
m_dispatch/dispatch-*.S, back into the scheduler, indicating somehow
that a transaction has failed. The scheduler can then fix up the guest
state, by popping guest-fail-handler off this thread's handler stack,
setting the guest state program counter to that value, and letting the
guest CPU resume.
What is crucial (and I was unable to determine from your description) is
that we cannot pass the guest's failure-handling address through to the
host, since otherwise we will permanently lose control of execution when
the transaction fails.
Whether or not the transactions on the host get nuked due to resource
constraints is orthogonal to the above proposal. In principle, if the
host has enough tracking resources, it could succeed.
Note that none of this involves changing the IR, so none of the tools
have to be aware that transactions are supported.
Does any of the above sync with how you did your Power implementation?
J
|
|
From: <sv...@va...> - 2013-08-16 12:11:29
|
dejanj 2013-08-16 13:11:20 +0100 (Fri, 16 Aug 2013)
New Revision: 2744
Log:
mips64: Fix a problem with CCall.retty type.
Fix a problem when CCall needs to return 64 bits
for return type.
Modified files:
trunk/priv/host_mips_isel.c
Modified: trunk/priv/host_mips_isel.c (+2 -2)
===================================================================
--- trunk/priv/host_mips_isel.c 2013-08-16 09:32:15 +01:00 (rev 2743)
+++ trunk/priv/host_mips_isel.c 2013-08-16 13:11:20 +01:00 (rev 2744)
@@ -1886,9 +1886,9 @@
vassert(ty == e->Iex.CCall.retty);
/* be very restrictive for now. Only 32/64-bit ints allowed for
- args, and 32 bits for return type. Don't forget to change
+ args, and 64 and 32 bits for return type. Don't forget to change
the RetLoc if more return types are allowed in future. */
- if (e->Iex.CCall.retty != Ity_I32)
+ if (e->Iex.CCall.retty != Ity_I64 && e->Iex.CCall.retty != Ity_I32)
goto irreducible;
/* Marshal args, do the call, clear stack. */
|
|
From: Philippe W. <phi...@sk...> - 2013-08-16 10:27:38
|
On Wed, 2013-08-14 at 08:44 -0700, Milind Chabbi wrote: > Resending my question. Is this the right mailing list to ask valgrind > internals question? Yes. > > > On Tue, Aug 13, 2013 at 12:19 PM, Milind Chabbi > <Mil...@ri...> wrote: > Hello, > > I am considering using Valgrind for a heavy-weight > instrumentation > that would instrument each memory access. > For detailed information about the access, I want to collect > the full > call path of each access. > Can someone tell me (at the high-level) what call path > collection > technique exists in Valgrind ? and give me some details of the > feature > such as algorithmic complexity of getting the call stack esp. > for each > instruction. Is it done using a stack unwinding technique or > it is > built on-the-fly via call-ret instructions? How is a call path > represented (is it an identifier to a call path object that > can be > queried at a later time) ? A stack trace is obtained by calling VG_(get_StackTrace) (see pub_tool_stacktrace.h). For frequent events (e.g. stacktraces of malloc,free,... in memcheck), there will be a lot of identical stacktraces. These can be maintained in a "dictionnary of stacktraces". See pub_tool_execontext.h. So, an execontext corresponds more or less to an "identifier ... that can be queried at a later time". Getting stacktraces is done via unwind technique, so is quite costly. Doing it for each memory access instruction will be very slow. The callgrind tool maintains the callstack on-the-fly via call-ret, but this callstack maintenance is specialised for callgrind. It might be an interesting project to generalise this callgrind callstack maintenance and make it "general" (i.e. part of the valgrind core framework) rather than tool specific. What kind of tool are you thinking to ? It might maybe easier to extend callgrind, which already captures memory access related information and callstack. Philippe |
|
From: <sv...@va...> - 2013-08-16 08:34:22
|
sewardj 2013-08-16 09:34:10 +0100 (Fri, 16 Aug 2013)
New Revision: 13501
Log:
Add test cases for 256-bit --partial-loads-ok=no|yes, by generalising the
128-bit versions. (Patrick J. LoPresti, lop...@gm...). Bug 294285.
Added files:
trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.stderr.exp
trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.stdout.exp
trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.vgtest
trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.stderr.exp
trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.stdout.exp
trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.vgtest
trunk/memcheck/tests/amd64/sh-mem-vec256.c
Modified files:
trunk/memcheck/tests/amd64/Makefile.am
trunk/memcheck/tests/amd64/sh-mem-vec128.c
trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-32bit-le
trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-64bit-le
trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-32bit-le
trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-64bit-le
trunk/memcheck/tests/common/sh-mem-vec128.tmpl.c
trunk/memcheck/tests/x86/sh-mem-vec128.c
Added: trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.vgtest (+4 -0)
===================================================================
--- trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.vgtest 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.vgtest 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -0,0 +1,4 @@
+prog: sh-mem-vec256
+prereq: ../../../tests/x86_amd64_features amd64-avx
+args: -q
+vgopts: --partial-loads-ok=no
Modified: trunk/memcheck/tests/common/sh-mem-vec128.tmpl.c (+48 -38)
===================================================================
--- trunk/memcheck/tests/common/sh-mem-vec128.tmpl.c 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/common/sh-mem-vec128.tmpl.c 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -1,7 +1,12 @@
-// Tests shadow memory correctness for 16-byte vector loads/stores
-// Requires vector16_copy() to be specified somehow.
+// Tests shadow memory correctness for 16-byte/32-byte/etc. vector
+// loads/stores. Requires vector_copy() and VECTOR_BYTES to be
+// specified somehow.
+#ifndef VECTOR_BYTES
+#error "VECTOR_BYTES must be defined"
+#endif
+
#include <assert.h>
#include <stdlib.h>
#include <stdio.h>
@@ -10,7 +15,7 @@
#include "memcheck/memcheck.h"
// What we're actually testing
-// .. is vector16_copy, which should be defined before this point
+// .. is vector_copy, which should be defined before this point
// All the sizes here are in *bytes*, not bits.
@@ -134,9 +139,9 @@
// Try doing some partial-loads-ok/not-ok testing.
/* Test cases:
- - load, 16-aligned, all no-access
+ - load, aligned, all no-access
==> addr err
- - load, 16-aligned, 1 to 15 initial bytes accessible,
+ - load, aligned, 1 to VECTOR_BYTES-1 initial bytes accessible,
then at least one unaccessible byte,
then remaining bytes in any state.
==> if PLO then no error, but returned V bits are undefined
@@ -144,7 +149,7 @@
else
error; and V bits are defined for unaccessible bytes
- All of the above, but non-16-aligned:
+ All of the above, but non-aligned:
-- all return an addressing error
*/
@@ -154,7 +159,10 @@
"------ PL %s case with %u leading acc+def bytes ------\n\n",
aligned ? "Aligned" : "Unaligned", nInitialValid);
- U1* block = memalign16(64);
+ void *temp;
+ if (posix_memalign(&temp, VECTOR_BYTES, 64) != 0)
+ abort();
+ U1* block = temp;
U4 j;
for (j = 0; j < 64; j++) block[j] = 0;
@@ -162,10 +170,10 @@
// Make the block have this pattern:
// block[0 .. i-1] accessible and defined
- // block[i .. 15] repeating NOACCESS, UNDEF, DEF
+ // block[i .. VECTOR_BYTES-1] repeating NOACCESS, UNDEF, DEF
// hence block[i], at the very least, is always NOACCESS
U4 i = nInitialValid;
- for (j = i; j < 16; j++) {
+ for (j = i; j < VECTOR_BYTES; j++) {
switch ((j-i) % 3) {
case 0: make_noaccess(&block[j]); break;
case 1: block[j] = make_undef(block[j]); break;
@@ -175,15 +183,15 @@
// Do the access, possibly generating an error, and show the
// resulting V bits
- U1 dst[16];
- vector16_copy(&dst[0], block);
+ U1 dst[VECTOR_BYTES];
+ vector_copy(&dst[0], block);
- U1 dst_vbits[16];
- U4 r = VALGRIND_GET_VBITS(&dst[0], &dst_vbits[0], 16);
+ U1 dst_vbits[VECTOR_BYTES];
+ U4 r = VALGRIND_GET_VBITS(&dst[0], &dst_vbits[0], VECTOR_BYTES);
assert(r == 1 || r == 0);
fprintf(stderr, "\n");
- for (j = 0; j < 16; j++) {
+ for (j = 0; j < VECTOR_BYTES; j++) {
fprintf(stderr, "%c", dst_vbits[j] == 0 ? 'd'
: dst_vbits[j] == 0xFF ? 'U' : '?');
}
@@ -192,7 +200,7 @@
// Also let's use the resulting value, to check we get an undef
// error
U1 sum = 0;
- for (j = 0; j < 16; j++)
+ for (j = 0; j < VECTOR_BYTES; j++)
sum ^= dst[j];
if (sum == 42) {
@@ -209,11 +217,14 @@
int main ( void )
{
- fprintf(stderr, "sh-mem-vec128: config: %s-endian, %d-bit word size\n",
- get_endianness(), (int)(8 * sizeof(void*)));
+ fprintf(stderr, "sh-mem-vec%d: config: %s-endian, %d-bit word size\n",
+ VECTOR_BYTES * 8, get_endianness(), (int)(8 * sizeof(void*)));
U4 i;
- U1* buf = memalign16(N_BYTES);
+ void *temp;
+ if (posix_memalign(&temp, VECTOR_BYTES, N_BYTES) != 0)
+ abort();
+ U1* buf = temp;
// Fill |buf| with bytes, so that zero bits have a zero shadow
// (are defined) and one bits have a one shadow (are undefined)
@@ -234,21 +245,21 @@
U4 n_fails = 0;
for (i = 0; i < n_copies; i++) {
- U4 si = randomU4() % (N_BYTES-16);
- U4 di = randomU4() % (N_BYTES-16);
- if (0 == (randomU1() & 7)) si &= ~(16-1);
- if (0 == (randomU1() & 7)) di &= ~(16-1);
- if (0 == (randomU1() & 63)) { di &= ~(16-1); si &= ~(16-1); }
+ U4 si = randomU4() % (N_BYTES-VECTOR_BYTES);
+ U4 di = randomU4() % (N_BYTES-VECTOR_BYTES);
+ if (0 == (randomU1() & 7)) si &= ~(VECTOR_BYTES-1);
+ if (0 == (randomU1() & 7)) di &= ~(VECTOR_BYTES-1);
+ if (0 == (randomU1() & 63)) { di &= ~(VECTOR_BYTES-1); si &= ~(VECTOR_BYTES-1); }
void* dst = &buf[di];
void* src = &buf[si];
- if (0 == (((UWord)src) & (16-1))) n_s_aligned++;
- if (0 == (((UWord)dst) & (16-1))) n_d_aligned++;
- if (0 == (((UWord)src) & (16-1)) && 0 == (((UWord)dst) & (16-1)))
+ if (0 == (((UWord)src) & (VECTOR_BYTES-1))) n_s_aligned++;
+ if (0 == (((UWord)dst) & (VECTOR_BYTES-1))) n_d_aligned++;
+ if (0 == (((UWord)src) & (VECTOR_BYTES-1)) && 0 == (((UWord)dst) & (VECTOR_BYTES-1)))
n_both_aligned++;
- vector16_copy(dst, src);
+ vector_copy(dst, src);
}
U4 freq[256];
@@ -280,31 +291,30 @@
// Check that we can detect underruns of the block.
fprintf(stderr, "\nExpect 2 x no error\n" );
- vector16_copy( &buf[100], &buf[0] );
- vector16_copy( &buf[0], &buf[100] );
+ vector_copy( &buf[100], &buf[0] );
+ vector_copy( &buf[0], &buf[100] );
fprintf(stderr, "\nExpect 2 x error\n\n" );
- vector16_copy( &buf[100], &buf[-1] ); // invalid rd
- vector16_copy( &buf[-1], &buf[100] ); // invalid wr
+ vector_copy( &buf[100], &buf[-1] ); // invalid rd
+ vector_copy( &buf[-1], &buf[100] ); // invalid wr
// and overruns ..
fprintf(stderr, "\nExpect 2 x no error\n" );
- vector16_copy( &buf[200], &buf[N_BYTES-16 + 0] );
- vector16_copy( &buf[N_BYTES-16 + 0], &buf[200] );
+ vector_copy( &buf[200], &buf[N_BYTES-VECTOR_BYTES + 0] );
+ vector_copy( &buf[N_BYTES-VECTOR_BYTES + 0], &buf[200] );
fprintf(stderr, "\nExpect 2 x error\n\n" );
- vector16_copy( &buf[200], &buf[N_BYTES-16 + 1] );
- vector16_copy( &buf[N_BYTES-16 + 1], &buf[200] );
+ vector_copy( &buf[200], &buf[N_BYTES-VECTOR_BYTES + 1] );
+ vector_copy( &buf[N_BYTES-VECTOR_BYTES + 1], &buf[200] );
free(buf);
fprintf(stderr, "\n");
- for (i = 0; i < 16; i++)
+ for (i = 0; i < VECTOR_BYTES; i++)
apply( do_partial_load_case, i, True/*aligned*/ );
- for (i = 0; i < 16; i++)
+ for (i = 0; i < VECTOR_BYTES; i++)
apply( do_partial_load_case, i, False/*not aligned*/ );
return 0;
}
-
Modified: trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-32bit-le (+20 -0)
===================================================================
--- trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-32bit-le 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-32bit-le 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -29,6 +29,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -35,6 +36,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -46,6 +48,7 @@
...
Address 0x........ is 79,985 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -52,6 +55,7 @@
...
Address 0x........ is 79,993 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -205,6 +209,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -220,6 +225,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -235,6 +241,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -250,6 +257,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -265,6 +273,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -280,6 +289,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -295,6 +305,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -310,6 +321,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -325,6 +337,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -340,6 +353,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -355,6 +369,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -370,6 +385,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -385,6 +401,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -400,6 +417,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -415,6 +433,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -430,6 +449,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Added: trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.stdout.exp (+0 -0)
===================================================================
Added: trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.vgtest (+4 -0)
===================================================================
--- trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.vgtest 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.vgtest 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -0,0 +1,4 @@
+prog: sh-mem-vec256
+prereq: ../../../tests/x86_amd64_features amd64-avx
+args: -q
+vgopts: --partial-loads-ok=yes
Added: trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.stderr.exp (+868 -0)
===================================================================
--- trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.stderr.exp 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.stderr.exp 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -0,0 +1,868 @@
+
+sh-mem-vec256: config: little-endian, 64-bit word size
+
+19543 109 126 31 206 54 112 34 102 152 335 1 36 0 23 33
+ 203 7 50 141 18 261 24 189 248 15 11 0 145 304 228 457
+ 4 367 20 32 269 3 319 51 448 85 88 166 21 228 238 41
+ 298 39 98 35 90 64 0 254 817 91 328 214 163 64 0 266
+ 214 347 234 32 536 233 13 171 91 42 332 189 177 14 81 142
+ 313 400 77 4 48 114 3 113 324 87 525 413 205 184 126 294
+ 182 0 244 88 0 254 45 134 226 248 0 27 262 0 173 244
+ 494 165 241 116 217 32 112 0 117 335 230 79 193 174 60 243
+ 19 94 163 16 59 184 1 79 247 214 378 142 239 253 0 61
+ 50 48 0 304 196 109 109 186 9 389 389 7 329 157 283 234
+ 4 724 74 247 99 92 35 376 242 54 309 549 23 264 61 143
+ 87 0 22 96 148 563 411 54 288 34 2 14 33 88 73 339
+ 122 18 347 145 208 251 266 265 3 261 146 207 831 213 146 59
+ 119 18 117 303 132 315 296 70 210 707 138 537 29 492 86 188
+ 292 6 312 158 32 107 0 259 53 379 45 115 38 324 36 32
+ 0 264 235 135 192 262 40 0 401 38 157 20 0 160 325 18430
+
+160000 copies, 26427 d_aligned, 26424 s_aligned, 6016 both_aligned
+0 failures
+
+Expect 2 x no error
+
+Expect 2 x error
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+Invalid write of size 8
+ ...
+ Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+Expect 2 x no error
+
+Expect 2 x error
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 79,969 bytes inside a block of size 80,000 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+Invalid write of size 8
+ ...
+ Address 0x........ is 79,993 bytes inside a block of size 80,000 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+------ PL Aligned case with 0 leading acc+def bytes ------
+
+
+UUdUUdUUdUUdUUdUUdUUdUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 1 leading acc+def bytes ------
+
+
+dUUdUUdUUdUUdUUdUUdUUdUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 2 leading acc+def bytes ------
+
+
+ddUUdUUdUUdUUdUUdUUdUUdUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 3 leading acc+def bytes ------
+
+
+dddUUdUUdUUdUUdUUdUUdUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 4 leading acc+def bytes ------
+
+
+ddddUUdUUdUUdUUdUUdUUdUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 5 leading acc+def bytes ------
+
+
+dddddUUdUUdUUdUUdUUdUUdUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 6 leading acc+def bytes ------
+
+
+ddddddUUdUUdUUdUUdUUdUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 7 leading acc+def bytes ------
+
+
+dddddddUUdUUdUUdUUdUUdUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 8 leading acc+def bytes ------
+
+
+ddddddddUUdUUdUUdUUdUUdUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 9 leading acc+def bytes ------
+
+
+dddddddddUUdUUdUUdUUdUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 10 leading acc+def bytes ------
+
+
+ddddddddddUUdUUdUUdUUdUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 11 leading acc+def bytes ------
+
+
+dddddddddddUUdUUdUUdUUdUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 12 leading acc+def bytes ------
+
+
+ddddddddddddUUdUUdUUdUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 13 leading acc+def bytes ------
+
+
+dddddddddddddUUdUUdUUdUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 14 leading acc+def bytes ------
+
+
+ddddddddddddddUUdUUdUUdUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 15 leading acc+def bytes ------
+
+
+dddddddddddddddUUdUUdUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 16 leading acc+def bytes ------
+
+
+ddddddddddddddddUUdUUdUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 17 leading acc+def bytes ------
+
+
+dddddddddddddddddUUdUUdUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 18 leading acc+def bytes ------
+
+
+ddddddddddddddddddUUdUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 19 leading acc+def bytes ------
+
+
+dddddddddddddddddddUUdUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 20 leading acc+def bytes ------
+
+
+ddddddddddddddddddddUUdUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 21 leading acc+def bytes ------
+
+
+dddddddddddddddddddddUUdUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 22 leading acc+def bytes ------
+
+
+ddddddddddddddddddddddUUdUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 23 leading acc+def bytes ------
+
+
+dddddddddddddddddddddddUUdUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 24 leading acc+def bytes ------
+
+
+ddddddddddddddddddddddddUUdUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 25 leading acc+def bytes ------
+
+
+dddddddddddddddddddddddddUUdUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 26 leading acc+def bytes ------
+
+
+ddddddddddddddddddddddddddUUdUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 27 leading acc+def bytes ------
+
+
+dddddddddddddddddddddddddddUUdUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 28 leading acc+def bytes ------
+
+
+ddddddddddddddddddddddddddddUUdU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 29 leading acc+def bytes ------
+
+
+dddddddddddddddddddddddddddddUUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 30 leading acc+def bytes ------
+
+
+ddddddddddddddddddddddddddddddUU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Aligned case with 31 leading acc+def bytes ------
+
+
+dddddddddddddddddddddddddddddddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 0 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dUddUddUddUddUddUddUddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 1 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddUddUddUddUddUddUddUddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 2 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddUddUddUddUddUddUddUddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 3 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddUddUddUddUddUddUddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 4 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddUddUddUddUddUddUddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 5 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddUddUddUddUddUddUddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 6 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddUddUddUddUddUddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 7 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddUddUddUddUddUddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 8 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddUddUddUddUddUddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 9 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddUddUddUddUddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 10 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddUddUddUddUddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 11 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddUddUddUddUddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 12 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddUddUddUddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 13 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddUddUddUddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 14 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddUddUddUddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 15 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddUddUddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 16 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddUddUddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 17 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddddUddUddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 18 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddUddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 19 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddddddUddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 20 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddddUddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 21 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddddddddUddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 22 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddddddUddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 23 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddddddddddUddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 24 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddddddddUddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 25 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddddddddddddUddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 26 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddddddddddUddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 27 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddddddddddddddUddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 28 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddddddddddddUdd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 29 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+ddddddddddddddddddddddddddddddUd
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 30 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddddddddddddddU
+
+Conditional jump or move depends on uninitialised value(s)
+ ...
+
+
+------ PL Unaligned case with 31 leading acc+def bytes ------
+
+Invalid read of size 32
+ ...
+ Address 0x........ is 1 bytes inside a block of size 64 alloc'd
+ at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
+ ...
+
+
+dddddddddddddddddddddddddddddddd
+
+
+
+HEAP SUMMARY:
+ in use at exit: 0 bytes in 0 blocks
+ total heap usage: 65 allocs, 65 frees, 84,096 bytes allocated
+
+For a detailed leak analysis, rerun with: --leak-check=full
+
+For counts of detected and suppressed errors, rerun with: -v
+Use --track-origins=yes to see where uninitialised values come from
+ERROR SUMMARY: 99 errors from 99 contexts (suppressed: 0 from 0)
Modified: trunk/memcheck/tests/amd64/sh-mem-vec128.c (+4 -2)
===================================================================
--- trunk/memcheck/tests/amd64/sh-mem-vec128.c 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/amd64/sh-mem-vec128.c 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -3,12 +3,14 @@
// required vector-copy function, and then including the
// template.
+#define VECTOR_BYTES 16
+
static __attribute__((noinline))
-void vector16_copy ( void* dst, void* src )
+void vector_copy ( void* dst, void* src )
{
__asm__ __volatile__(
"movups (%1), %%xmm7 ; movups %%xmm7, (%0)"
- : /*OUT*/ : /*IN*/ "r"(dst), "r"(src) : "memory","xmm7"
+ : /*OUT*/ : /*IN*/ "r"(dst), "r"(src) : "memory","xmm7"
);
}
Modified: trunk/memcheck/tests/x86/sh-mem-vec128.c (+4 -2)
===================================================================
--- trunk/memcheck/tests/x86/sh-mem-vec128.c 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/x86/sh-mem-vec128.c 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -3,12 +3,14 @@
// required vector-copy function, and then including the
// template.
+#define VECTOR_BYTES 16
+
static __attribute__((noinline))
-void vector16_copy ( void* dst, void* src )
+void vector_copy ( void* dst, void* src )
{
__asm__ __volatile__(
"movups (%1), %%xmm7 ; movups %%xmm7, (%0)"
- : /*OUT*/ : /*IN*/ "r"(dst), "r"(src) : "memory","xmm7"
+ : /*OUT*/ : /*IN*/ "r"(dst), "r"(src) : "memory","xmm7"
);
}
Modified: trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-64bit-le (+20 -0)
===================================================================
--- trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-64bit-le 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/common/sh-mem-vec128-plo-yes.stderr.exp-64bit-le 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -29,6 +29,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -35,6 +36,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -46,6 +48,7 @@
...
Address 0x........ is 79,985 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -52,6 +55,7 @@
...
Address 0x........ is 79,993 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -205,6 +209,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -220,6 +225,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -235,6 +241,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -250,6 +257,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -265,6 +273,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -280,6 +289,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -295,6 +305,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -310,6 +321,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -325,6 +337,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -340,6 +353,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -355,6 +369,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -370,6 +385,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -385,6 +401,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -400,6 +417,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -415,6 +433,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -430,6 +449,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Added: trunk/memcheck/tests/amd64/sh-mem-vec256-plo-yes.stdout.exp (+0 -0)
===================================================================
Modified: trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-32bit-le (+36 -0)
===================================================================
--- trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-32bit-le 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-32bit-le 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -29,6 +29,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -35,6 +36,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -46,6 +48,7 @@
...
Address 0x........ is 79,985 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -52,6 +55,7 @@
...
Address 0x........ is 79,993 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -61,6 +65,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -76,6 +81,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -91,6 +97,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -106,6 +113,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -121,6 +129,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -136,6 +145,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -151,6 +161,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -166,6 +177,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -181,6 +193,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -196,6 +209,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -211,6 +225,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -226,6 +241,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -241,6 +257,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -256,6 +273,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -271,6 +289,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -286,6 +305,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -298,6 +318,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -313,6 +334,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -328,6 +350,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -343,6 +366,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -358,6 +382,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -373,6 +398,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -388,6 +414,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -403,6 +430,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -418,6 +446,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -433,6 +462,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -448,6 +478,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -463,6 +494,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -478,6 +510,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -493,6 +526,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -508,6 +542,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -523,6 +558,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Modified: trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-64bit-le (+36 -0)
===================================================================
--- trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-64bit-le 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/common/sh-mem-vec128-plo-no.stderr.exp-64bit-le 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -29,6 +29,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -35,6 +36,7 @@
...
Address 0x........ is 1 bytes before a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -46,6 +48,7 @@
...
Address 0x........ is 79,985 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Invalid write of size 8
@@ -52,6 +55,7 @@
...
Address 0x........ is 79,993 bytes inside a block of size 80,000 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -61,6 +65,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -76,6 +81,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -91,6 +97,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -106,6 +113,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -121,6 +129,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -136,6 +145,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -151,6 +161,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -166,6 +177,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -181,6 +193,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -196,6 +209,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -211,6 +225,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -226,6 +241,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -241,6 +257,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -256,6 +273,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -271,6 +289,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -286,6 +305,7 @@
...
Address 0x........ is 0 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -298,6 +318,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -313,6 +334,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -328,6 +350,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -343,6 +366,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -358,6 +382,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -373,6 +398,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -388,6 +414,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -403,6 +430,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -418,6 +446,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -433,6 +462,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -448,6 +478,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -463,6 +494,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -478,6 +510,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -493,6 +526,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -508,6 +542,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
@@ -523,6 +558,7 @@
...
Address 0x........ is 1 bytes inside a block of size 64 alloc'd
at 0x........: memalign (vg_replace_malloc.c:...)
+ by 0x........: posix_memalign (vg_replace_malloc.c:...)
...
Added: trunk/memcheck/tests/amd64/sh-mem-vec256.c (+21 -0)
===================================================================
--- trunk/memcheck/tests/amd64/sh-mem-vec256.c 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/amd64/sh-mem-vec256.c 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -0,0 +1,21 @@
+
+// Set up the 256-bit shadow memory test, by defining the
+// required vector-copy function, and then including the
+// template.
+
+#define VECTOR_BYTES 32
+
+static __attribute__((noinline))
+void vector_copy ( void* dst, void* src )
+{
+ /* Note: Verions of GCC through 4.8.1 do not allow "ymm7" in the
+ clobber list. (See http://stackoverflow.com/a/15767111/768469).
+ Simulate it with "xmm7". */
+ __asm__ __volatile__(
+ "vmovupd (%1), %%ymm7 ; vmovupd %%ymm7, (%0)"
+ : /*OUT*/ : /*IN*/ "r"(dst), "r"(src) : "memory","xmm7"
+ );
+}
+
+// Include the test body, which refers to the above function
+#include "../common/sh-mem-vec128.tmpl.c"
Added: trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.stderr.exp (+942 -0)
===================================================================
--- trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.stderr.exp 2013-08-16 09:31:29 +01:00 (rev 13500)
+++ trunk/memcheck/tests/amd64/sh-mem-vec256-plo-no.stderr.exp 2013-08-16 09:34:10 +01:00 (rev 13501)
@@ -0,0 +1,942 @@
+
+sh-mem-vec256: config: little-endian, 64-bit word size
+
+19543 109 126 31 206 54 112 34 102 152 335 1 36 0 23 33
+ 203 7 50 141 18 261 24 189 248 15 11 0 145 304 228 457
+ 4 367 20 32 269 3 319 51 448 85 88 166 21 228 238 41
+ 298 39 98 3...
[truncated message content] |
|
From: <sv...@va...> - 2013-08-16 08:32:25
|
sewardj 2013-08-16 09:32:15 +0100 (Fri, 16 Aug 2013)
New Revision: 2743
Log:
Add support for 256-bit return values for dirty helpers (amd64 only).
(Patrick J. LoPresti, lop...@gm...). Bug 294285.
Modified files:
trunk/priv/host_amd64_isel.c
Modified: trunk/priv/host_amd64_isel.c (+14 -3)
===================================================================
--- trunk/priv/host_amd64_isel.c 2013-08-15 21:54:52 +01:00 (rev 2742)
+++ trunk/priv/host_amd64_isel.c 2013-08-16 09:32:15 +01:00 (rev 2743)
@@ -603,7 +603,6 @@
addInstr(env, mk_iMOVsd_RR( hregAMD64_RSP(), r_vecRetAddr ));
}
else if (retTy == Ity_V256) {
- vassert(0); //ATC
r_vecRetAddr = newVRegI(env);
sub_from_rsp(env, 32);
addInstr(env, mk_iMOVsd_RR( hregAMD64_RSP(), r_vecRetAddr ));
@@ -680,7 +679,6 @@
*stackAdjustAfterCall = 16;
break;
case Ity_V256:
- vassert(0); // ATC
*retloc = mk_RetLoc_spRel(RLPri_V256SpRel, 0);
*stackAdjustAfterCall = 32;
break;
@@ -4443,7 +4441,7 @@
switch (retty) {
case Ity_INVALID: /* function doesn't return anything */
case Ity_I64: case Ity_I32: case Ity_I16: case Ity_I8:
- case Ity_V128:
+ case Ity_V128: case Ity_V256:
retty_ok = True; break;
default:
break;
@@ -4490,6 +4488,19 @@
add_to_rsp(env, addToSp);
return;
}
+ case Ity_V256: {
+ /* See comments for Ity_V128. */
+ vassert(rloc.pri == RLPri_V256SpRel);
+ vassert(addToSp >= 32);
+ HReg dstLo, dstHi;
+ lookupIRTempPair(&dstHi, &dstLo, env, d->tmp);
+ AMD64AMode* amLo = AMD64AMode_IR(rloc.spOff, hregAMD64_RSP());
+ addInstr(env, AMD64Instr_SseLdSt( True/*load*/, 16, dstLo, amLo ));
+ AMD64AMode* amHi = AMD64AMode_IR(rloc.spOff+16, hregAMD64_RSP());
+ addInstr(env, AMD64Instr_SseLdSt( True/*load*/, 16, dstHi, amHi ));
+ add_to_rsp(env, addToSp);
+ return;
+ }
default:
/*NOTREACHED*/
vassert(0);
|
|
From: <sv...@va...> - 2013-08-16 08:31:40
|
sewardj 2013-08-16 09:31:29 +0100 (Fri, 16 Aug 2013)
New Revision: 13500
Log:
Add support for direct V256 shadow helper returns -- memcheck side.
(Patrick J. LoPresti, lop...@gm...). Bug 294285.
Modified files:
trunk/memcheck/mc_include.h
trunk/memcheck/mc_main.c
trunk/memcheck/mc_translate.c
Modified: trunk/memcheck/mc_main.c (+61 -54)
===================================================================
--- trunk/memcheck/mc_main.c 2013-08-15 22:18:21 +01:00 (rev 13499)
+++ trunk/memcheck/mc_main.c 2013-08-16 09:31:29 +01:00 (rev 13500)
@@ -1130,14 +1130,11 @@
static
__attribute__((noinline))
-void mc_LOADV128_slow ( /*OUT*/V128* res, Addr a, Bool bigendian )
+void mc_LOADVx_slow ( /*OUT*/ULong* res, Addr a, SizeT nBits, Bool bigendian )
{
- SizeT nBits = 128;
- V128 vbits128; /* result */
- V128 pessim128; /* only used when p-l-ok=yes */
- SSizeT bytes_per_long = 64 / 8;
- SSizeT szL = nBits / 64; /* Size in longs */
- SSizeT szB = bytes_per_long * szL;
+ ULong pessim[4]; /* only used when p-l-ok=yes */
+ SSizeT szB = nBits / 8;
+ SSizeT szL = szB / 8; /* Size in longs */
SSizeT i, j; /* Must be signed. */
SizeT n_addrs_bad = 0;
Addr ai;
@@ -1144,29 +1141,34 @@
UChar vbits8;
Bool ok;
- vbits128.w64[0] = V_BITS64_UNDEFINED;
- vbits128.w64[1] = V_BITS64_UNDEFINED;
- pessim128.w64[0] = V_BITS64_DEFINED;
- pessim128.w64[1] = V_BITS64_DEFINED;
+ /* Code below assumes load size is a power of two and at least 64
+ bits. */
+ tl_assert((szB & (szB-1)) == 0 && szL > 0);
- tl_assert(nBits == 128);
+ /* If this triggers, you probably just need to increase the size of
+ the pessim array. */
+ tl_assert(szL <= sizeof(pessim) / sizeof(pessim[0]));
- /* Make up a 128-bit result V word, which contains the loaded data
- for valid addresses and Defined for invalid addresses. Iterate
- over the bytes in the word, from the most significant down to
- the least. The vbits to return are calculated into vbits128.
- Also compute the pessimising value to be used when
+ for (j=0 ; j < szL ; j++) {
+ pessim[j] = V_BITS64_DEFINED;
+ res[j] = V_BITS64_UNDEFINED;
+ }
+
+ /* Make up a result V word, which contains the loaded data for
+ valid addresses and Defined for invalid addresses. Iterate over
+ the bytes in the word, from the most significant down to the
+ least. The vbits to return are calculated into vbits128. Also
+ compute the pessimising value to be used when
--partial-loads-ok=yes. n_addrs_bad is redundant (the relevant
- info can be gleaned from pessim128) but is used as a
+ info can be gleaned from the pessim array) but is used as a
cross-check. */
for (j = szL-1 ; j >= 0 ; j--) {
ULong vbits64 = V_BITS64_UNDEFINED;
ULong pessim64 = V_BITS64_DEFINED;
UWord long_index = byte_offset_w(szL, bigendian, j);
- for (i = bytes_per_long-1; i >= 0; i--) {
+ for (i = 8-1; i >= 0; i--) {
PROF_EVENT(31, "mc_LOADV128_slow(loop)");
- ai = a + long_index*bytes_per_long + byte_offset_w(bytes_per_long,
- bigendian, i);
+ ai = a + 8*long_index + byte_offset_w(8, bigendian, i);
ok = get_vbits8(ai, &vbits8);
vbits64 <<= 8;
vbits64 |= vbits8;
@@ -1174,22 +1176,19 @@
pessim64 <<= 8;
pessim64 |= (ok ? V_BITS8_DEFINED : V_BITS8_UNDEFINED);
}
- vbits128.w64[long_index] = vbits64;
- pessim128.w64[long_index] = pessim64;
+ res[long_index] = vbits64;
+ pessim[long_index] = pessim64;
}
/* In the common case, all the addresses involved are valid, so we
just return the computed V bits and have done. */
- if (LIKELY(n_addrs_bad == 0)) {
- *res = vbits128;
+ if (LIKELY(n_addrs_bad == 0))
return;
- }
/* If there's no possibility of getting a partial-loads-ok
exemption, report the error and quit. */
if (!MC_(clo_partial_loads_ok)) {
MC_(record_address_error)( VG_(get_running_tid)(), a, szB, False );
- *res = vbits128;
return;
}
@@ -1199,7 +1198,7 @@
false negatives. If it doesn't apply, just report an addressing
error in the usual way. */
- /* Some code steps along byte strings in aligned word-sized chunks
+ /* Some code steps along byte strings in aligned chunks
even when there is only a partially defined word at the end (eg,
optimised strlen). This is allowed by the memory model of
modern machines, since an aligned load cannot span two pages and
@@ -1217,21 +1216,22 @@
*/
/* "at least one of the addresses is invalid" */
- tl_assert(pessim128.w64[0] != V_BITS64_DEFINED
- || pessim128.w64[1] != V_BITS64_DEFINED);
+ ok = False;
+ for (j=0 ; j < szL ; j++)
+ ok |= pessim[j] != V_BITS8_DEFINED;
+ tl_assert(ok);
if (0 == (a & (szB - 1)) && n_addrs_bad < szB) {
/* Exemption applies. Use the previously computed pessimising
- value for vbits128 and return the combined result, but don't
- flag an addressing error. The pessimising value is Defined
- for valid addresses and Undefined for invalid addresses. */
+ value and return the combined result, but don't flag an
+ addressing error. The pessimising value is Defined for valid
+ addresses and Undefined for invalid addresses. */
/* for assumption that doing bitwise or implements UifU */
tl_assert(V_BIT_UNDEFINED == 1 && V_BIT_DEFINED == 0);
/* (really need "UifU" here...)
- vbits128 UifU= pessim128 (is pessimised by it, iow) */
+ vbits[j] UifU= pessim[j] (is pessimised by it, iow) */
for (j = szL-1 ; j >= 0 ; j--)
- vbits128.w64[j] |= pessim128.w64[j];
- *res = vbits128;
+ res[j] |= pessim[j];
return;
}
@@ -1238,8 +1238,6 @@
/* Exemption doesn't apply. Flag an addressing error in the normal
way. */
MC_(record_address_error)( VG_(get_running_tid)(), a, szB, False );
-
- *res = vbits128;
}
@@ -4207,12 +4205,12 @@
/* ------------------------ Size = 16 ------------------------ */
static INLINE
-void mc_LOADV128 ( /*OUT*/V128* res, Addr a, Bool isBigEndian )
+void mc_LOADVx ( /*OUT*/ULong* res, Addr a, SizeT nBits, Bool isBigEndian )
{
- PROF_EVENT(200, "mc_LOADV128");
+ PROF_EVENT(200, "mc_LOADVx");
#ifndef PERF_FAST_LOADV
- mc_LOADV128_slow( res, a, isBigEndian );
+ mc_LOADVx_slow( res, a, nBits, isBigEndian );
return;
#else
{
@@ -4219,16 +4217,17 @@
UWord sm_off16, vabits16;
SecMap* sm;
int j;
+ int nBytes = nBits / 8;
- if (UNLIKELY( UNALIGNED_OR_HIGH(a,128) )) {
- PROF_EVENT(201, "mc_LOADV128-slow1");
- mc_LOADV128_slow( res, a, isBigEndian );
+ if (UNLIKELY( UNALIGNED_OR_HIGH(a,nBits) )) {
+ PROF_EVENT(201, "mc_LOADVx-slow1");
+ mc_LOADVx_slow( res, a, nBits, isBigEndian );
return;
}
- // Handle common cases quickly: a (and a+8) is suitably aligned,
- // is mapped, and addressible.
- for (j=0 ; j<2 ; ++j) {
+ /* Handle common cases quickly: a (and a+8 and a+16 etc.) is
+ suitably aligned, is mapped, and addressible. */
+ for (j=0 ; j<nBytes/8 ; ++j) {
sm = get_secmap_for_reading_low(a + 8*j);
sm_off16 = SM_OFF_16(a + 8*j);
vabits16 = ((UShort*)(sm->vabits8))[sm_off16];
@@ -4236,14 +4235,14 @@
// Convert V bits from compact memory form to expanded
// register form.
if (LIKELY(vabits16 == VA_BITS16_DEFINED)) {
- res->w64[j] = V_BITS64_DEFINED;
+ res[j] = V_BITS64_DEFINED;
} else if (LIKELY(vabits16 == VA_BITS16_UNDEFINED)) {
- res->w64[j] = V_BITS64_UNDEFINED;
+ res[j] = V_BITS64_UNDEFINED;
} else {
/* Slow case: some block of 8 bytes are not all-defined or
all-undefined. */
- PROF_EVENT(202, "mc_LOADV128-slow2");
- mc_LOADV128_slow( res, a, isBigEndian );
+ PROF_EVENT(202, "mc_LOADVx-slow2");
+ mc_LOADVx_slow( res, a, nBits, isBigEndian );
return;
}
}
@@ -4252,16 +4251,24 @@
#endif
}
+VG_REGPARM(2) void MC_(helperc_LOADV256be) ( /*OUT*/V256* res, Addr a )
+{
+ mc_LOADVx(&res->w64[0], a, 256, True);
+}
+VG_REGPARM(2) void MC_(helperc_LOADV256le) ( /*OUT*/V256* res, Addr a )
+{
+ mc_LOADVx(&res->w64[0], a, 256, False);
+}
+
VG_REGPARM(2) void MC_(helperc_LOADV128be) ( /*OUT*/V128* res, Addr a )
{
- mc_LOADV128(res, a, True);
+ mc_LOADVx(&res->w64[0], a, 128, True);
}
VG_REGPARM(2) void MC_(helperc_LOADV128le) ( /*OUT*/V128* res, Addr a )
{
- mc_LOADV128(res, a, False);
+ mc_LOADVx(&res->w64[0], a, 128, False);
}
-
/* ------------------------ Size = 8 ------------------------ */
static INLINE
Modified: trunk/memcheck/mc_include.h (+2 -0)
===================================================================
--- trunk/memcheck/mc_include.h 2013-08-15 22:18:21 +01:00 (rev 13499)
+++ trunk/memcheck/mc_include.h 2013-08-16 09:31:29 +01:00 (rev 13500)
@@ -580,6 +580,8 @@
VG_REGPARM(2) void MC_(helperc_STOREV16le) ( Addr, UWord );
VG_REGPARM(2) void MC_(helperc_STOREV8) ( Addr, UWord );
+VG_REGPARM(2) void MC_(helperc_LOADV256be) ( /*OUT*/V256*, Addr );
+VG_REGPARM(2) void MC_(helperc_LOADV256le) ( /*OUT*/V256*, Addr );
VG_REGPARM(2) void MC_(helperc_LOADV128be) ( /*OUT*/V128*, Addr );
VG_REGPARM(2) void MC_(helperc_LOADV128le) ( /*OUT*/V128*, Addr );
VG_REGPARM(1) ULong MC_(helperc_LOADV64be) ( Addr );
Modified: trunk/memcheck/mc_translate.c (+17 -26)
===================================================================
--- trunk/memcheck/mc_translate.c 2013-08-15 22:18:21 +01:00 (rev 13499)
+++ trunk/memcheck/mc_translate.c 2013-08-16 09:31:29 +01:00 (rev 13500)
@@ -4183,8 +4183,8 @@
The definedness of |guard| itself is not checked. That is assumed
to have been done before this point, by the caller. */
static
-IRAtom* expr2vbits_Load_WRK ( MCEnv* mce,
- IREndness end, IRType ty,
+IRAtom* expr2vbits_Load_WRK ( MCEnv* mce,
+ IREndness end, IRType ty,
IRAtom* addr, UInt bias, IRAtom* guard )
{
tl_assert(isOriginalAtom(mce,addr));
@@ -4202,8 +4202,12 @@
const HChar* hname = NULL;
Bool ret_via_outparam = False;
- if (end == Iend_LE) {
+ if (end == Iend_LE) {
switch (ty) {
+ case Ity_V256: helper = &MC_(helperc_LOADV256le);
+ hname = "MC_(helperc_LOADV256le)";
+ ret_via_outparam = True;
+ break;
case Ity_V128: helper = &MC_(helperc_LOADV128le);
hname = "MC_(helperc_LOADV128le)";
ret_via_outparam = True;
@@ -4225,6 +4229,10 @@
}
} else {
switch (ty) {
+ case Ity_V256: helper = &MC_(helperc_LOADV256be);
+ hname = "MC_(helperc_LOADV256be)";
+ ret_via_outparam = True;
+ break;
case Ity_V128: helper = &MC_(helperc_LOADV128be);
hname = "MC_(helperc_LOADV128be)";
ret_via_outparam = True;
@@ -4309,37 +4317,20 @@
definedness of |guard| before this point.
*/
static
-IRAtom* expr2vbits_Load ( MCEnv* mce,
- IREndness end, IRType ty,
+IRAtom* expr2vbits_Load ( MCEnv* mce,
+ IREndness end, IRType ty,
IRAtom* addr, UInt bias,
IRAtom* guard )
{
tl_assert(end == Iend_LE || end == Iend_BE);
switch (shadowTypeV(ty)) {
- case Ity_I8:
- case Ity_I16:
- case Ity_I32:
+ case Ity_I8:
+ case Ity_I16:
+ case Ity_I32:
case Ity_I64:
case Ity_V128:
+ case Ity_V256:
return expr2vbits_Load_WRK(mce, end, ty, addr, bias, guard);
- case Ity_V256: {
- /* V256-bit case -- phrased in terms of 64 bit units (Qs),
- with Q3 being the most significant lane. */
- if (end == Iend_BE) goto unhandled;
- IRAtom* v64Q0
- = expr2vbits_Load_WRK(mce, end, Ity_I64, addr, bias+0, guard);
- IRAtom* v64Q1
- = expr2vbits_Load_WRK(mce, end, Ity_I64, addr, bias+8, guard);
- IRAtom* v64Q2
- = expr2vbits_Load_WRK(mce, end, Ity_I64, addr, bias+16, guard);
- IRAtom* v64Q3
- = expr2vbits_Load_WRK(mce, end, Ity_I64, addr, bias+24, guard);
- return assignNew( 'V', mce,
- Ity_V256,
- IRExpr_Qop(Iop_64x4toV256,
- v64Q3, v64Q2, v64Q1, v64Q0));
- }
- unhandled:
default:
VG_(tool_panic)("expr2vbits_Load");
}
|
|
From: Philippe W. <phi...@sk...> - 2013-08-16 03:50:51
|
valgrind revision: 13499 VEX revision: 2742 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-08-15 20:00:08 PDT Ended at 2013-08-15 20:50:18 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 == 558 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-08-16 03:24:06
|
valgrind revision: 13499 VEX revision: 2742 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-08-16 03:52:38 BST Ended at 2013-08-16 04:23: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 == 637 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-08-16 03:18:54
|
valgrind revision: 13499 VEX revision: 2742 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-08-16 03:42:16 BST Ended at 2013-08-16 04:18:37 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 == 639 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-08-16 03:16:09
|
valgrind revision: 13499 VEX revision: 2742 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-08-16 03:32:49 BST Ended at 2013-08-16 04:15:46 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 == 639 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-08-16 03:01:55
|
valgrind revision: 13499 VEX revision: 2742 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-08-16 03:13:34 BST Ended at 2013-08-16 04:01:34 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 == 660 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-08-16 03:01:26
|
valgrind revision: 13499 VEX revision: 2742 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-08-16 03:21:58 BST Ended at 2013-08-16 04:01:09 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 == 658 tests, 1 stderr failure, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) |