Valgrind, an open-source memory debugger

On 29/09/11 11:09, Gaetano Mendola wrote:

> I'm getting the following error running my application with valgrind:
>
> vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x7 0x48 0xF 0x5A 0x4F
> ==31136== valgrind: Unrecognised instruction at address 0x1f2a2c20.
> ==31136==    at 0x1F2A2C20: ??? (in
> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)
> ==31136==    by 0x1F2A1FAE: y8_ownippsSum_32f (in
> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)
> ==31136==    by 0x1F2FDE5C: y8_ownippsMean_32f (in
> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)
> ==31136==    by 0x1F1A2D31: y8_ippsMean_32f (in
> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)

That's CVTPS2PD which looks like it has been supported for ages. What 
version of valgrind are you using?

Tom

-- 
Tom Hughes (tom@...)
http://compton.nu/

On 29/09/11 11:44, Gaetano Mendola wrote:
> On Thu, Sep 29, 2011 at 12:34 PM, Tom Hughes<tom@...>  wrote:
>> On 29/09/11 11:09, Gaetano Mendola wrote:
>>
>>> I'm getting the following error running my application with valgrind:
>>>
>>> vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x7 0x48 0xF
>>> 0x5A 0x4F
>>> ==31136== valgrind: Unrecognised instruction at address 0x1f2a2c20.
>>> ==31136==    at 0x1F2A2C20: ??? (in
>>> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)
>>> ==31136==    by 0x1F2A1FAE: y8_ownippsSum_32f (in
>>> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)
>>> ==31136==    by 0x1F2FDE5C: y8_ownippsMean_32f (in
>>> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)
>>> ==31136==    by 0x1F1A2D31: y8_ippsMean_32f (in
>>> /opt/intel/composerxe-2011.1.107/ipp/lib/intel64/libippsy8.so.7.0)
>>
>> That's CVTPS2PD which looks like it has been supported for ages. What
>> version of valgrind are you using?
>
> $ valgrind --version
> valgrind-3.7.0.SVN

Ah I see - the issue is that it has REX.W set (the 0x48 prefix) which is 
redundant for that instruction as only REX.R has any effect on it.

It has already been reported here:

https://bugs.kde.org/show_bug.cgi?id=278744

Tom

-- 
Tom Hughes (tom@...)
http://compton.nu/

On 29/09/11 13:16, Gaetano Mendola wrote:
> On Thu, Sep 29, 2011 at 1:06 PM, Tom Hughes<tom@...>  wrote:
>
>> Ah I see - the issue is that it has REX.W set (the 0x48 prefix) which is
>> redundant for that instruction as only REX.R has any effect on it.
>>
>> It has already been reported here:
>>
>> https://bugs.kde.org/show_bug.cgi?id=278744
>
> Is there a work around then ?

Well the workaround is not to add useless space wasting bytes to the 
instruction, but as this instruction is in IPP that probably doesn't 
help you much ;-)

Other than that you need to get your hands dirty in the VEX code.

Tom

-- 
Tom Hughes (tom@...)
http://compton.nu/

On Thu, Sep 29, 2011 at 2:18 PM, Tom Hughes <tom@...> wrote:
> On 29/09/11 13:16, Gaetano Mendola wrote:
>>
>> On Thu, Sep 29, 2011 at 1:06 PM, Tom Hughes<tom@...>  wrote:
>>
>>> Ah I see - the issue is that it has REX.W set (the 0x48 prefix) which is
>>> redundant for that instruction as only REX.R has any effect on it.
>>>
>>> It has already been reported here:
>>>
>>> https://bugs.kde.org/show_bug.cgi?id=278744
>>
>> Is there a work around then ?
>
> Well the workaround is not to add useless space wasting bytes to the
> instruction, but as this instruction is in IPP that probably doesn't help
> you much ;-)
>
> Other than that you need to get your hands dirty in the VEX code.

I'm not familiar at all with that code :(, and to be honest I have never
seen it. Any chance of an hot fix ?


-- 
cpp-today.blogspot.com