<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.kde.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugs.kde.org/"
          
          maintainer="sysadmin@kde.org"
>

    <bug>
          <bug_id>258870</bug_id>
          
          <creation_ts>2010-12-05 03:40:05 +0000</creation_ts>
          <short_desc>Add support for EXTRACTPS SSE 4.1 instruction in libVEX</short_desc>
          <delta_ts>2011-01-19 13:24:22 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>6</classification_id>
          <classification>Developer tools</classification>
          <product>valgrind</product>
          <component>vex</component>
          <version>3.7 SVN</version>
          <rep_platform>Compiled Sources</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>NOR</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>0</everconfirmed>
          <reporter name="Veselin Georgiev">anrieff</reporter>
          <assigned_to name="Julian Seward">jseward</assigned_to>
          
          
          <cf_commitlink></cf_commitlink>
          <cf_versionfixedin></cf_versionfixedin>
          <cf_sentryurl></cf_sentryurl>
          <votes>0</votes>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1053651</commentid>
    <comment_count>0</comment_count>
      <attachid>54129</attachid>
    <who name="Veselin Georgiev">anrieff</who>
    <bug_when>2010-12-05 03:40:05 +0000</bug_when>
    <thetext>Created attachment 54129
extractps addition to libvex

Hello,

I am new to this, so please be lenient.

I&apos;ve implemented the extractps instruction into libvex out of necessity.
I was hunting down a bug in a plugin for Autodesk Maya 2011 for Mac OS X on a Snow Leopard machine. However, while the application seems to start up under valgrind, at some point it halts because of an unhandled instruction, which turned out to be EXTRACTPS. So I got the SVN code and confirmed there is no support for the instruction in libVEX and so I investigated whether I could implement it. It turned out being easy, since the instruction is all very similar to the already present PEXTRD (the only difference between them is that PEXTRD cannot have a 64-bit destination register (with REX.W on, it becomes PEXTRQ); however, EXTRACTPS can output to a 64-bit general purpose register in which case the upper 32bits of the destination are zeroed - see http://www.intel.com/technology/itj/2008/v12i3/3-paper/4-SSE.htm ).

So at this point I have:

* (Probably) A working implementation of EXTRACTPS in libVEX; it borrows code from PEXTRD and handles the 64-bit case. See the attached .diff file.
* A custom test program that is not integrated in any way into the valgrind&apos;s test system. I didn&apos;t figure out how to run the tests anyway. But I&apos;ve written this small program which issues EXTACTPS&apos;es with all kinds of parameters and assert()s validity of outputs (tests all output options - r32, r64 and mem32). With real hardware no assert is triggered, same for valgrind, so it seems to work. Maya 2011 also ran after fine with this fix.

So I&apos;m attaching this addition to libVEX here so you can review it. Also, can you point me how can I produce a test case for EXTRACTPS that fits into valgrind nicely? I can also give you my test program so you can adapt it, but that could be on Monday since I forgot it at work.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1074496</commentid>
    <comment_count>1</comment_count>
    <who name="Julian Seward">jseward</who>
    <bug_when>2011-01-17 11:40:47 +0000</bug_when>
    <thetext>Fixed, vex r2076.  Thanks for the patch.  I committed 
something a bit simpler because I think putIReg32(...)
generates the correct semantics all the time.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1074774</commentid>
    <comment_count>2</comment_count>
      <attachid>56144</attachid>
    <who name="Veselin Georgiev">anrieff</who>
    <bug_when>2011-01-17 20:24:14 +0000</bug_when>
    <thetext>Created attachment 56144
extractps testing utility</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1074775</commentid>
    <comment_count>3</comment_count>
      <attachid>56145</attachid>
    <who name="Veselin Georgiev">anrieff</who>
    <bug_when>2011-01-17 20:25:05 +0000</bug_when>
    <thetext>Created attachment 56145
A patch against VEX</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1074778</commentid>
    <comment_count>4</comment_count>
    <who name="Veselin Georgiev">anrieff</who>
    <bug_when>2011-01-17 20:25:58 +0000</bug_when>
    <thetext>(In reply to comment #1)
&gt; Fixed, vex r2076.  Thanks for the patch.  I committed 
&gt; something a bit simpler because I think putIReg32(...)
&gt; generates the correct semantics all the time.

Hello again,

thanks for including this. Unfortunately, I still think that the code now in VEX is incomplete, as it doesn&apos;t catch the 64-bit destination-operand case. I updated the to the latest SVN and, when running my extractps-testing tool under valgrind, it fails with:

vex amd64-&gt;IR: unhandled instruction bytes: 0x66 0x48 0xF 0x3A 0x17 0xF8 0xF0 0x48
==4999== valgrind: Unrecognised instruction at address 0x10000092c.
=
...

This is the 64-bit case (e.g., &quot;extractps  $0xf0, %%xmm7, %%rax&quot;).
The 32-bit cases work fine though.
Also, I don&apos;t know why, but under 64-bit Linux the code currently in VEX also works flawlessly.
So I&apos;m only experiencing the problem under Apple/64-bit.

I&apos;m attaching the tool I use for testing (to be compiled with any 64-bit gcc).
I&apos;m also attaching a patch against the current code in VEX that fixes the 64-bit problem.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1074866</commentid>
    <comment_count>5</comment_count>
    <who name="Julian Seward">jseward</who>
    <bug_when>2011-01-17 23:59:22 +0000</bug_when>
    <thetext>(In reply to comment #4)

&gt; vex amd64-&gt;IR: unhandled instruction bytes: 0x66 0x48 0xF 0x3A 0x17 0xF8 0xF0
&gt; 0x48
&gt; Also, I don&apos;t know why, but under 64-bit Linux the code currently in VEX also
&gt; works flawlessly.

It&apos;s because the Apple assembler inserts a redundant REX.W prefix
byte.  Compare the bytes in the failure message

   0x66 0x48 0xF 0x3A 0x17 0xF8 0xF0

to objdump of the Linux binary

  4006a1:	66 0f 3a 17 f8 f0    	extractps $0xf0,%xmm7,%eax

there is no 48 after the 66 here.


Instead of the patch in comment 3, can you try this?  It is the
same as yours, except it also allows a redundant REX.W==1 for the
memory case, which I think would be OK.

Index: VEX/priv/guest_amd64_toIR.c
===================================================================
--- VEX/priv/guest_amd64_toIR.c	(revision 2079)
+++ VEX/priv/guest_amd64_toIR.c	(working copy)
@@ -14649,7 +14649,7 @@
       identical to PEXTRD, except that REX.W appears to be ignored.
    */
    if ( have66noF2noF3( pfx ) 
-        &amp;&amp; sz == 2  /* REX.W == 0; perhaps too strict? */
+        &amp;&amp; (sz == 2 || /* ignore redundant REX.W */ sz == 8)
         &amp;&amp; insn[0] == 0x0F &amp;&amp; insn[1] == 0x3A &amp;&amp; insn[2] == 0x17 ) {
 
       Int imm8_10;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1075009</commentid>
    <comment_count>6</comment_count>
    <who name="Veselin Georgiev">anrieff</who>
    <bug_when>2011-01-18 11:53:27 +0000</bug_when>
    <thetext>(In reply to comment #5)
&gt; (In reply to comment #4)
&gt; 
&gt; &gt; vex amd64-&gt;IR: unhandled instruction bytes: 0x66 0x48 0xF 0x3A 0x17 0xF8 0xF0
&gt; &gt; 0x48
&gt; &gt; Also, I don&apos;t know why, but under 64-bit Linux the code currently in VEX also
&gt; &gt; works flawlessly.
&gt; 
&gt; It&apos;s because the Apple assembler inserts a redundant REX.W prefix
&gt; byte.  Compare the bytes in the failure message
&gt; 
&gt;    0x66 0x48 0xF 0x3A 0x17 0xF8 0xF0
&gt; 
&gt; to objdump of the Linux binary
&gt; 
&gt;   4006a1:    66 0f 3a 17 f8 f0        extractps $0xf0,%xmm7,%eax
&gt; 
&gt; there is no 48 after the 66 here.
&gt; 
&gt; 
&gt; Instead of the patch in comment 3, can you try this?  It is the
&gt; same as yours, except it also allows a redundant REX.W==1 for the
&gt; memory case, which I think would be OK.
&gt; 
&gt; Index: VEX/priv/guest_amd64_toIR.c
&gt; ===================================================================
&gt; --- VEX/priv/guest_amd64_toIR.c    (revision 2079)
&gt; +++ VEX/priv/guest_amd64_toIR.c    (working copy)
&gt; @@ -14649,7 +14649,7 @@
&gt;        identical to PEXTRD, except that REX.W appears to be ignored.
&gt;     */
&gt;     if ( have66noF2noF3( pfx ) 
&gt; -        &amp;&amp; sz == 2  /* REX.W == 0; perhaps too strict? */
&gt; +        &amp;&amp; (sz == 2 || /* ignore redundant REX.W */ sz == 8)
&gt;          &amp;&amp; insn[0] == 0x0F &amp;&amp; insn[1] == 0x3A &amp;&amp; insn[2] == 0x17 ) {
&gt; 
&gt;        Int imm8_10;

Ah! Of course, you are right. I tried your patch - it works now under OS X.
I knew it was strange to get different results between OS X and Linux...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1075527</commentid>
    <comment_count>7</comment_count>
    <who name="Julian Seward">jseward</who>
    <bug_when>2011-01-19 13:24:22 +0000</bug_when>
    <thetext>Followup fixed committed as vex r2081.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>54129</attachid>
            <date>2010-12-05 03:40:05 +0000</date>
            <delta_ts>2010-12-05 03:40:05 +0000</delta_ts>
            <desc>extractps addition to libvex</desc>
            <filename>extractps.diff</filename>
            <type>text/plain</type>
            <size>3944</size>
            <attacher name="Veselin Georgiev">anrieff</attacher>
            
              <data encoding="base64">SW5kZXg6IFZFWC9wcml2L2d1ZXN0X2FtZDY0X3RvSVIuYwo9PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBWRVgvcHJp
di9ndWVzdF9hbWQ2NF90b0lSLmMJKHJldmlzaW9uIDIwNjkpCisrKyBWRVgvcHJpdi9ndWVzdF9h
bWQ2NF90b0lSLmMJKHdvcmtpbmcgY29weSkKQEAgLTE0MjM3LDcgKzE0MjM3LDkyIEBACiAgICAg
ICBnb3RvIGRlY29kZV9zdWNjZXNzOwogICAgfQogCisgICAvKiA2NiAwRiAzQSAxNyAvciBpYiA9
IEVYVEFDVFBTIHJlZy9tZW0zMiwgeG1tMiwgaW1tOAorICAgICAgRXh0cmFjdCBQYWNrZWQgU2lu
Z2xlIHByZWNpc2lvbiBGbG9hdGluZy1Qb2ludCB2YWx1ZSAKKyAgICAgIGZyb20geG1tIHJlZyBh
bmQgc3RvcmUgaW4gZ2VuLnJlZyBvciBtZW0uIChYTU0pIAorICAgICAgVGhlIGluc3RydWN0aW9u
IG9wZXJhdGVzIG11Y2ggdGhlIHNhbWUgd2F5IGFzIFBFWFRSRCwKKyAgICAgIHRoZSBvbmx5IGRp
ZmZlcmVuY2UgYmVpbmcgdGhhdCB0aGUgZGVzdGluYXRpb24gY2FuIGJlCisgICAgICBhIDY0LWJp
dCByZWcsIGFuZCwgaWYgc28sIHRoZSB1cHBlciAzMiBiaXRzIG9mIGRlc3RpbmF0aW9uCisgICAg
ICBhcmUgY2xlYXJlZC4gKi8KKyAgIGlmICggaGF2ZTY2bm9GMm5vRjMoIHBmeCApIAorICAgICAg
ICAmJiBpbnNuWzBdID09IDB4MEYgJiYgaW5zblsxXSA9PSAweDNBICYmIGluc25bMl0gPT0gMHgx
NyAKKyAgICAgICAgJiYgKCBzeiA9PSAyICAgICAgICAgICAgICAgICAgICAgICAgLyogZGVzdGlu
YXRpb24gY2FuIGJlIG1lbTMyL3JlZzMyLi4uICovCisgICAgICAgICAgICAgfHwgKCBzeiA9PSA4
ICYmIGVwYXJ0SXNSZWcoaW5zblszXSkgKSkpIHsgIC8qIC4uLiBvciByZWc2NCAgICAgICAgICAq
LwogCisgICAgICBJbnQgaW1tOF8xMDsKKyAgICAgIElSVGVtcCB4bW1fdmVjICAgPSBuZXdUZW1w
KEl0eV9WMTI4KTsKKyAgICAgIElSVGVtcCBzcmNfMzJvcjY0OworCisgICAgICBtb2RybSA9IGlu
c25bM107CisgICAgICBhc3NpZ24oIHhtbV92ZWMsIGdldFhNTVJlZyggZ3JlZ09mUmV4Uk0ocGZ4
LG1vZHJtKSApICk7CisgICAgICBicmVha3VwMTI4dG8zMnMoIHhtbV92ZWMsICZ0MywgJnQyLCAm
dDEsICZ0MCApOworCisgICAgICBpZiAoIGVwYXJ0SXNSZWcoIG1vZHJtICkgKSB7CisgICAgICAg
ICBpbW04XzEwID0gKEludCkoaW5zblszKzFdICYgMyk7CisgICAgICB9IGVsc2UgeyAKKyAgICAg
ICAgIGFkZHIgPSBkaXNBTW9kZSggJmFsZW4sIHZiaSwgcGZ4LCBkZWx0YSszLCBkaXNfYnVmLCAx
ICk7CisgICAgICAgICBpbW04XzEwID0gKEludCkoaW5zblszK2FsZW5dICYgMyk7CisgICAgICB9
CisKKyAgICAgIGlmIChzeiA9PSAyKSB7CisgICAgICAgICBzcmNfMzJvcjY0ID0gbmV3VGVtcChJ
dHlfSTMyKTsKKyAgICAgICAgIHN3aXRjaCAoIGltbThfMTAgKSB7CisgICAgICAgICAgICBjYXNl
IDA6ICBhc3NpZ24oIHNyY18zMm9yNjQsIG1rZXhwcih0MCkgKTsgYnJlYWs7CisgICAgICAgICAg
ICBjYXNlIDE6ICBhc3NpZ24oIHNyY18zMm9yNjQsIG1rZXhwcih0MSkgKTsgYnJlYWs7CisgICAg
ICAgICAgICBjYXNlIDI6ICBhc3NpZ24oIHNyY18zMm9yNjQsIG1rZXhwcih0MikgKTsgYnJlYWs7
CisgICAgICAgICAgICBjYXNlIDM6ICBhc3NpZ24oIHNyY18zMm9yNjQsIG1rZXhwcih0MykgKTsg
YnJlYWs7CisgICAgICAgICAgICBkZWZhdWx0OiB2YXNzZXJ0KDApOworICAgICAgICAgfQorICAg
ICAgfSBlbHNlIHsKKyAgICAgICAgIHNyY18zMm9yNjQgPSBuZXdUZW1wKEl0eV9JNjQpOworICAg
ICAgICAgSVJUZW1wIHplcm9fMzIgPSBuZXdUZW1wKEl0eV9JMzIpOworICAgICAgICAgYXNzaWdu
KCB6ZXJvXzMyLCBta1UzMigwKSApOworICAgICAgICAgc3dpdGNoICggaW1tOF8xMCApIHsKKyAg
ICAgICAgICAgIGNhc2UgMDogIGFzc2lnbiggc3JjXzMyb3I2NCwgYmlub3AoIElvcF8zMkhMdG82
NCwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1rZXhw
cih6ZXJvXzMyKSwKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG1rZXhwcih0MCkgKSApOworICAgICAgICAgICAgICAgICAgICAgYnJlYWs7CisgICAgICAg
ICAgICBjYXNlIDE6ICBhc3NpZ24oIHNyY18zMm9yNjQsIGJpbm9wKCBJb3BfMzJITHRvNjQsCisg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBta2V4cHIoemVy
b18zMiksCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBt
a2V4cHIodDEpICkgKTsKKyAgICAgICAgICAgICAgICAgICAgIGJyZWFrOworICAgICAgICAgICAg
Y2FzZSAyOiAgYXNzaWduKCBzcmNfMzJvcjY0LCBiaW5vcCggSW9wXzMySEx0bzY0LAorICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWtleHByKHplcm9fMzIp
LAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbWtleHBy
KHQyKSApICk7CisgICAgICAgICAgICAgICAgICAgICBicmVhazsKKyAgICAgICAgICAgIGNhc2Ug
MzogIGFzc2lnbiggc3JjXzMyb3I2NCwgYmlub3AoIElvcF8zMkhMdG82NCwKKyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1rZXhwcih6ZXJvXzMyKSwKKyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1rZXhwcih0Mykg
KSApOworICAgICAgICAgICAgICAgICAgICAgYnJlYWs7CisgICAgICAgICAgICBkZWZhdWx0OiB2
YXNzZXJ0KDApOworICAgICAgICAgfQorICAgICAgfQorCisgICAgICBpZiAoIGVwYXJ0SXNSZWco
IG1vZHJtICkgKSB7CisgICAgICAgICBpZiAoc3ogPT0gMikgeworICAgICAgICAgICAgcHV0SVJl
ZzMyKCBlcmVnT2ZSZXhSTShwZngsbW9kcm0pLCBta2V4cHIoc3JjXzMyb3I2NCkgKTsKKyAgICAg
ICAgICAgIGRlbHRhICs9IDMrMSsxOworICAgICAgICAgICAgRElQKCAiZXh0cmFjdHBzICQlZCwg
JXMsJXNcbiIsIGltbThfMTAsCisgICAgICAgICAgICAgICAgIG5hbWVYTU1SZWcoIGdyZWdPZlJl
eFJNKHBmeCwgbW9kcm0pICksCisgICAgICAgICAgICAgICAgIG5hbWVJUmVnMzIoIGVyZWdPZlJl
eFJNKHBmeCwgbW9kcm0pICkgKTsKKyAgICAgICAgIH0gZWxzZSB7CisgICAgICAgICAgICBwdXRJ
UmVnNjQoIGVyZWdPZlJleFJNKHBmeCxtb2RybSksIG1rZXhwcihzcmNfMzJvcjY0KSApOworICAg
ICAgICAgICAgZGVsdGEgKz0gMysxKzE7CisgICAgICAgICAgICBESVAoICJleHRyYWN0cHMgJCVk
LCAlcywlc1xuIiwgaW1tOF8xMCwKKyAgICAgICAgICAgICAgICAgbmFtZVhNTVJlZyggZ3JlZ09m
UmV4Uk0ocGZ4LCBtb2RybSkgKSwKKyAgICAgICAgICAgICAgICAgbmFtZUlSZWc2NCggZXJlZ09m
UmV4Uk0ocGZ4LCBtb2RybSkgKSApOworICAgICAgICAgfQorICAgICAgfSBlbHNlIHsKKyAgICAg
ICAgIHN0b3JlTEUoIG1rZXhwcihhZGRyKSwgbWtleHByKHNyY18zMm9yNjQpICk7CisgICAgICAg
ICBkZWx0YSArPSAzK2FsZW4rMTsKKyAgICAgICAgIERJUCggImV4dHJhY3RwcyAkJWQsICVzLCVz
XG4iLCAKKyAgICAgICAgICAgICAgaW1tOF8xMCwgbmFtZVhNTVJlZyggZ3JlZ09mUmV4Uk0ocGZ4
LCBtb2RybSkgKSwgZGlzX2J1ZiApOworICAgICAgfQorCisgICAgICBnb3RvIGRlY29kZV9zdWNj
ZXNzOworICAgfQorCisKICAgLyogNjYgMEYgM0EgMTQgL3IgaWIgPSBQRVhUUkIgci9tMTYsIHht
bSwgaW1tOAogICAgICBFeHRyYWN0IEJ5dGUgZnJvbSB4bW0sIHN0b3JlIGluIG1lbSBvciB6ZXJv
LWV4dGVuZCArIHN0b3JlIGluIGdlbi5yZWcuIChYTU0pICovCiAgIGlmICggaGF2ZTY2bm9GMm5v
RjMoIHBmeCApIAo=
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>56144</attachid>
            <date>2011-01-17 20:24:14 +0000</date>
            <delta_ts>2011-01-17 20:24:14 +0000</delta_ts>
            <desc>extractps testing utility</desc>
            <filename>testExtract.c</filename>
            <type>text/x-csrc</type>
            <size>3528</size>
            <attacher name="Veselin Georgiev">anrieff</attacher>
            
              <data encoding="base64">I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxhc3NlcnQuaD4KCnN0YXRpYyBmbG9hdCB4WzRd
IF9fYXR0cmlidXRlX18oKGFsaWduZWQoMTYpKSkgPSB7IDEuMCwgMi4wLCAzLjAsIDQuNSB9OwoK
aW50IHRlc3QzMmJpdChpbnQgd2hpY2gpCnsKCWludCB5ID0gMTg3ODI7Cglzd2l0Y2ggKHdoaWNo
KSB7CgkJY2FzZSAwOiB7CgkJCV9fYXNtIF9fdm9sYXRpbGUoCgkJCQkJCQkgIgltb3ZhcHMJCSUx
LAklJXhtbTdcbiIKCQkJCQkJCSAiCWV4dHJhY3RwcwkkMCwJJSV4bW03LAklJWVheFxuIgoJCQkJ
CQkJICIJbW92CQkJJSVlYXgsCSUwXG4iCgkJCQkJCQkgOiI9bSIoeSkKCQkJCQkJCSA6Im0iKCp4
KQoJCQkJCQkJIDoiZWF4Iik7CgkJCWJyZWFrOwoJCX0KCQljYXNlIDE6IHsKCQkJX19hc20gX192
b2xhdGlsZSgKCQkJCQkJCSAiCW1vdmFwcwkJJTEsCSUleG1tN1xuIgoJCQkJCQkJICIJZXh0cmFj
dHBzCSQxLAklJXhtbTcsCSUlZWF4XG4iCgkJCQkJCQkgIgltb3YJCQklJWVheCwJJTBcbiIKCQkJ
CQkJCSA6Ij1tIih5KQoJCQkJCQkJIDoibSIoKngpCgkJCQkJCQkgOiJlYXgiKTsKCQkJYnJlYWs7
CgkJfQoJCWNhc2UgMjogewoJCQlfX2FzbSBfX3ZvbGF0aWxlKAoJCQkJCQkJICIJbW92YXBzCQkl
MSwJJSV4bW04XG4iCgkJCQkJCQkgIglleHRyYWN0cHMJJDIsCSUleG1tOCwJJSVlYXhcbiIKCQkJ
CQkJCSAiCW1vdgkJCSUlZWF4LAklMFxuIgoJCQkJCQkJIDoiPW0iKHkpCgkJCQkJCQkgOiJtIigq
eCkKCQkJCQkJCSA6ImVheCIpOwoJCQlicmVhazsKCQl9CgkJY2FzZSAzOiB7CgkJCV9fYXNtIF9f
dm9sYXRpbGUoCgkJCQkJCQkgIgltb3ZhcHMJCSUxLAklJXhtbTlcbiIKCQkJCQkJCSAiCWV4dHJh
Y3RwcwkkNywJJSV4bW05LAklJWVkeFxuIgoJCQkJCQkJICIJbW92CQkJJSVlZHgsCSUwXG4iCgkJ
CQkJCQkgOiI9bSIoeSkKCQkJCQkJCSA6Im0iKCp4KQoJCQkJCQkJIDoiZWR4Iik7CgkJCWJyZWFr
OwoJCX0KCX0KCXJldHVybiB5Owp9Cgp2b2lkIHRlc3QzMm1lbShpbnQgd2hpY2gsIGludCogcmVz
dWx0KQp7Cglzd2l0Y2ggKHdoaWNoKSB7CgkJY2FzZSAwOiB7CgkJCV9fYXNtIF9fdm9sYXRpbGUo
CgkJCQkJCQkgIgltb3YJCQklMSwJJSVyYXhcbiIKCQkJCQkJCSAiCW1vdmFwcwkJJTAsCSUleG1t
N1xuIgoJCQkJCQkJICIJZXh0cmFjdHBzCSQweGY0LCUleG1tNywJKCUlcmF4KVxuIgoJCQkJCQkJ
IDo6Im0iKCp4KSwgIm0iKHJlc3VsdCkKCQkJCQkJCSA6Im1lbW9yeSIsICJyYXgiKTsKCQkJYnJl
YWs7CgkJfQoJCWNhc2UgMTogewoJCQlfX2FzbSBfX3ZvbGF0aWxlKAoJCQkJCQkJICIJbW92CQkJ
JTEsCSUlcmF4XG4iCgkJCQkJCQkgIgltb3ZhcHMJCSUwLAklJXhtbThcbiIKCQkJCQkJCSAiCWV4
dHJhY3RwcwkkMHgxNSwlJXhtbTgsCSglJXJheClcbiIKCQkJCQkJCSA6OiJtIigqeCksICJtIihy
ZXN1bHQpCgkJCQkJCQkgOiJtZW1vcnkiLCAicmF4Iik7CgkJCWJyZWFrOwoJCX0KCQljYXNlIDI6
IHsKCQkJX19hc20gX192b2xhdGlsZSgKCQkJCQkJCSAiCW1vdgkJCSUxLAklJXJkeFxuIgoJCQkJ
CQkJICIJbW92YXBzCQklMCwJJSV4bW05XG4iCgkJCQkJCQkgIglleHRyYWN0cHMJJDB4NDIsJSV4
bW05LAkoJSVyZHgpXG4iCgkJCQkJCQkgOjoibSIoKngpLCAibSIocmVzdWx0KQoJCQkJCQkJIDoi
bWVtb3J5IiwgInJkeCIpOwoJCQlicmVhazsKCQl9CgkJY2FzZSAzOiB7CgkJCV9fYXNtIF9fdm9s
YXRpbGUoCgkJCQkJCQkgIgltb3YJCQklMSwJJSVyZGlcbiIKCQkJCQkJCSAiCW1vdmFwcwkJJTAs
CSUleG1tMFxuIgoJCQkJCQkJICIJZXh0cmFjdHBzCSQweDgzLAklJXhtbTAsCSglJXJkaSlcbiIK
CQkJCQkJCSA6OiJtIigqeCksICJtIihyZXN1bHQpCgkJCQkJCQkgOiJtZW1vcnkiLCAicmRpIik7
CgkJCWJyZWFrOwoJCX0KCX0KfQoKdW5zaWduZWQgbG9uZyBsb25nIHRlc3Q2NGJpdChpbnQgd2hp
Y2gpCnsKCXVuc2lnbmVkIGxvbmcgbG9uZyB5ID0gNzEyNjMxOwoJc3dpdGNoICh3aGljaCkgewoJ
CWNhc2UgMDogewoJCQlfX2FzbSBfX3ZvbGF0aWxlKAoJCQkJCQkJICIJbW92YXBzCQklMSwJJSV4
bW03XG4iCgkJCQkJCQkgIglleHRyYWN0cHMJJDB4ZjAsCSUleG1tNywJJSVyYXhcbiIKCQkJCQkJ
CSAiCW1vdgkJCSUlcmF4LAklMFxuIgoJCQkJCQkJIDoiPW0iKHkpCgkJCQkJCQkgOiJtIigqeCkK
CQkJCQkJCSA6InJheCIpOwoJCQlicmVhazsKCQl9CgkJY2FzZSAxOiB7CgkJCV9fYXNtIF9fdm9s
YXRpbGUoCgkJCQkJCQkgIgltb3ZhcHMJCSUxLAklJXhtbTdcbiIKCQkJCQkJCSAiCWV4dHJhY3Rw
cwkkMHhlMSwJJSV4bW03LAklJXIxM1xuIgoJCQkJCQkJICIJbW92CQkJJSVyMTMsCSUwXG4iCgkJ
CQkJCQkgOiI9bSIoeSkKCQkJCQkJCSA6Im0iKCp4KQoJCQkJCQkJIDoicjEzIik7CgkJCWJyZWFr
OwoJCX0KCQljYXNlIDI6IHsKCQkJX19hc20gX192b2xhdGlsZSgKCQkJCQkJCSAiCW1vdmFwcwkJ
JTEsCSUleG1tOFxuIgoJCQkJCQkJICIJZXh0cmFjdHBzCSQweDIyLAklJXhtbTgsCSUlcjlcbiIK
CQkJCQkJCSAiCW1vdgkJCSUlcjksCSUwXG4iCgkJCQkJCQkgOiI9bSIoeSkKCQkJCQkJCSA6Im0i
KCp4KQoJCQkJCQkJIDoicjkiKTsKCQkJYnJlYWs7CgkJfQoJCWNhc2UgMzogewoJCQlfX2FzbSBf
X3ZvbGF0aWxlKAoJCQkJCQkJICIJbW92YXBzCQklMSwJJSV4bW05XG4iCgkJCQkJCQkgIglleHRy
YWN0cHMJJDMsCSUleG1tOSwJJSVyZHhcbiIKCQkJCQkJCSAiCW1vdgkJCSUlcmR4LAklMFxuIgoJ
CQkJCQkJIDoiPW0iKHkpCgkJCQkJCQkgOiJtIigqeCkKCQkJCQkJCSA6InJkeCIpOwoJCQlicmVh
azsKCQl9Cgl9CglyZXR1cm4geTsKfQoKCgppbnQgbWFpbih2b2lkKQp7CglpbnQqIHRlc3R1bmcg
PSAoaW50KikgeDsKCXVuc2lnbmVkKiB1dGVzdCA9ICh1bnNpZ25lZCopIHg7Cglhc3NlcnQodGVz
dDMyYml0KDApID09IHRlc3R1bmdbMF0pOwoJYXNzZXJ0KHRlc3QzMmJpdCgxKSA9PSB0ZXN0dW5n
WzFdKTsKCWFzc2VydCh0ZXN0MzJiaXQoMikgPT0gdGVzdHVuZ1syXSk7Cglhc3NlcnQodGVzdDMy
Yml0KDMpID09IHRlc3R1bmdbM10pOwoJaW50IHhyZXM7Cgl0ZXN0MzJtZW0oMCwgJnhyZXMpOwoJ
YXNzZXJ0KHhyZXMgPT0gdGVzdHVuZ1swXSk7Cgl0ZXN0MzJtZW0oMSwgJnhyZXMpOwoJYXNzZXJ0
KHhyZXMgPT0gdGVzdHVuZ1sxXSk7Cgl0ZXN0MzJtZW0oMiwgJnhyZXMpOwoJYXNzZXJ0KHhyZXMg
PT0gdGVzdHVuZ1syXSk7Cgl0ZXN0MzJtZW0oMywgJnhyZXMpOwoJYXNzZXJ0KHhyZXMgPT0gdGVz
dHVuZ1szXSk7Cglhc3NlcnQodGVzdDY0Yml0KDApID09ICh1bnNpZ25lZCBsb25nIGxvbmcpIHV0
ZXN0WzBdKTsKCWFzc2VydCh0ZXN0NjRiaXQoMSkgPT0gKHVuc2lnbmVkIGxvbmcgbG9uZykgdXRl
c3RbMV0pOwoJYXNzZXJ0KHRlc3Q2NGJpdCgyKSA9PSAodW5zaWduZWQgbG9uZyBsb25nKSB1dGVz
dFsyXSk7Cglhc3NlcnQodGVzdDY0Yml0KDMpID09ICh1bnNpZ25lZCBsb25nIGxvbmcpIHV0ZXN0
WzNdKTsKCQoJcHJpbnRmKCJUZXN0IHBhc3NlZCBPSyFcbiIpOwoJcmV0dXJuIDA7Cn0K
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>56145</attachid>
            <date>2011-01-17 20:25:05 +0000</date>
            <delta_ts>2011-01-17 20:25:05 +0000</delta_ts>
            <desc>A patch against VEX</desc>
            <filename>vexpatch.diff</filename>
            <type>text/plain</type>
            <size>527</size>
            <attacher name="Veselin Georgiev">anrieff</attacher>
            
              <data encoding="base64">SW5kZXg6IHByaXYvZ3Vlc3RfYW1kNjRfdG9JUi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHByaXYvZ3Vlc3Rf
YW1kNjRfdG9JUi5jCShyZXZpc2lvbiAyMDc5KQorKysgcHJpdi9ndWVzdF9hbWQ2NF90b0lSLmMJ
KHdvcmtpbmcgY29weSkKQEAgLTE0NjQ5LDcgKzE0NjQ5LDcgQEAKICAgICAgIGlkZW50aWNhbCB0
byBQRVhUUkQsIGV4Y2VwdCB0aGF0IFJFWC5XIGFwcGVhcnMgdG8gYmUgaWdub3JlZC4KICAgICov
CiAgICBpZiAoIGhhdmU2Nm5vRjJub0YzKCBwZnggKSAKLSAgICAgICAgJiYgc3ogPT0gMiAgLyog
UkVYLlcgPT0gMDsgcGVyaGFwcyB0b28gc3RyaWN0PyAqLworICAgICAgICAmJiAoc3ogPT0gMiB8
fCAoc3ogPT0gOCAmJiBlcGFydElzUmVnKGluc25bM10pKSkKICAgICAgICAgJiYgaW5zblswXSA9
PSAweDBGICYmIGluc25bMV0gPT0gMHgzQSAmJiBpbnNuWzJdID09IDB4MTcgKSB7CiAKICAgICAg
IEludCBpbW04XzEwOwo=
</data>

          </attachment>
      

    </bug>

</bugzilla>