Bug 278744 - cvtps2pd with redundant RexW: vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x7 0x48 0xF 0x5A 0x4F
Summary: cvtps2pd with redundant RexW: vex amd64->IR: unhandled instruction bytes: 0x4...
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: vex (show other bugs)
Version: 3.7 SVN
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
: 288274 329245 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-29 01:08 UTC by Nathan Stratton
Modified: 2015-10-12 14:32 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Fix relative to 3.8.1 release (482 bytes, patch)
2013-09-09 17:12 UTC, Griffin Myers
Details
Fix relative to current SVN HEAD (r2755) (544 bytes, patch)
2013-09-09 17:14 UTC, Griffin Myers
Details
redundantRexW testcase extension for cvtps2pd (2.28 KB, patch)
2015-10-09 20:56 UTC, Mark Wielaard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan Stratton 2011-07-29 01:08:49 UTC
Ran this by a Intel guy and he says this uses valid instructions. Any idea how to fix this?

vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x7 0x48 0xF 0x5A 0x4F
==30567== valgrind: Unrecognised instruction at address 0x886f810.
==30567==    at 0x886F810: ??? (in /opt/intel/composerxe-2011.2.137/ipp/lib/intel64/libippsy8.so.7.0)
==30567==    by 0x10E962D: Psychoacoustic (aac_enc_psychoacoustic_fp.c:483)
==30567==    by 0x10DEF45: aacencGetFrame (aac_enc_api_fp.c:1141)
==30567==    by 0x10DAB99: UMC::AACEncoder::GetFrame(UMC::MediaData*, UMC::MediaData*) (umc_aac_encoder.cpp:339)
==30567==    by 0x87FB53: bm::rtp::AACPacketProcessor::send(bm::audio::LinearAudioUnit&) (aacpacketprocessor.cpp:173)
==30567==    by 0x8E42BB: bm::Bridge::process(bm::events::bridge::OutboundLinearAudioUnit const&) (bridge.cpp:687)
==30567==    by 0x8AC0E1: bm::events::bridge::OutboundLinearAudioUnit::processBy(bm::scheduling::Bus&) const (events.h:1053)
==30567==    by 0x95A253: bm::scheduling::Bus::process(bm::events::Event const&) (bus.cpp:25)
==30567==    by 0x8F6925: bm::Bridge::process(bm::events::Event&) (bridge.cpp:1659)
==30567==    by 0x8ED68F: bm::Bridge::processExternalEvents(int, short) (bridge.cpp:1151)
==30567==    by 0x8FB03F: bm::Bridge::processExternalEvents(int, short, void*) (bridge.cpp:1790)
==30567==    by 0x52AAD18: event_base_loop (event.c:395)
==30567==    by 0x8ECF30: bm::Bridge::run() (bridge.cpp:1065)
==30567==    by 0x95A176: boost::_mfi::mf0<void, bm::Bridge>::operator()(bm::Bridge*) const (mem_fn_template.hpp:49)
==30567==    by 0x95A06D: void boost::_bi::list1<boost::_bi::value<bm::Bridge*> >::operator()<boost::_mfi::mf0<void, bm::Bridge>, boost::_bi::list0>(boost::_bi::type<void>, boost::_mfi::mf0<void, bm::Bridge>&, boost::_bi::list0&, int) (bind.hpp:253)
==30567==    by 0x959FD2: boost::_bi::bind_t<void, boost::_mfi::mf0<void, bm::Bridge>, boost::_bi::list1<boost::_bi::value<bm::Bridge*> > >::operator()() (bind_template.hpp:20)
==30567==    by 0x9591B7: boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, bm::Bridge>, boost::_bi::list1<boost::_bi::value<bm::Bridge*> > > >::run() (thread.hpp:61)
==30567==    by 0x54CDA54: thread_proxy (in /usr/lib64/libboost_thread-mt.so.1.44.0)
==30567==    by 0x91D0CCA: start_thread (pthread_create.c:301)
==30567==    by 0xBD26C2C: clone (clone.S:115)
==30567== Your program just tried to execute an instruction that Valgrind
==30567== did not recognise.  There are two possible reasons for this.
==30567== 1. Your program has a bug and erroneously jumped to a non-code
==30567==    location.  If you are running Memcheck and you just saw a
==30567==    warning about a bad jump, it's probably your program's fault.
==30567== 2. The instruction is legitimate but Valgrind doesn't handle it,
==30567==    i.e. it's Valgrind's fault.  If you think this is the case or
==30567==    you are not sure, please let us know and we'll try to fix it.
==30567== Either way, Valgrind will now raise a SIGILL signal which will
==30567== probably kill your program.
==30567== 
==30567== Process terminating with default action of signal 4 (SIGILL): dumping core
==30567==  Illegal opcode at address 0x886F810
==30567==    at 0x886F810: ??? (in /opt/intel/composerxe-2011.2.137/ipp/lib/intel64/libippsy8.so.7.0)
==30567==    by 0x10E962D: Psychoacoustic (aac_enc_psychoacoustic_fp.c:483)
==30567==    by 0x10DEF45: aacencGetFrame (aac_enc_api_fp.c:1141)
==30567==    by 0x10DAB99: UMC::AACEncoder::GetFrame(UMC::MediaData*, UMC::MediaData*) (umc_aac_encoder.cpp:339)
==30567==    by 0x87FB53: bm::rtp::AACPacketProcessor::send(bm::audio::LinearAudioUnit&) (aacpacketprocessor.cpp:173)
==30567==    by 0x8E42BB: bm::Bridge::process(bm::events::bridge::OutboundLinearAudioUnit const&) (bridge.cpp:687)
==30567==    by 0x8AC0E1: bm::events::bridge::OutboundLinearAudioUnit::processBy(bm::scheduling::Bus&) const (events.h:1053)
==30567==    by 0x95A253: bm::scheduling::Bus::process(bm::events::Event const&) (bus.cpp:25)
==30567==    by 0x8F6925: bm::Bridge::process(bm::events::Event&) (bridge.cpp:1659)
==30567==    by 0x8ED68F: bm::Bridge::processExternalEvents(int, short) (bridge.cpp:1151)
==30567==    by 0x8FB03F: bm::Bridge::processExternalEvents(int, short, void*) (bridge.cpp:1790)
==30567==    by 0x52AAD18: event_base_loop (event.c:395)
Comment 1 Tom Hughes 2011-08-10 14:45:16 UTC
This is a CVTPS2PD instruction.
Comment 2 Tom Hughes 2011-08-10 14:46:33 UTC
The problem is the 0x48 (REX.W) prefix which we're not expecting - it is likely redundant.
Comment 3 Tom Hughes 2011-12-05 16:22:50 UTC
*** Bug 288274 has been marked as a duplicate of this bug. ***
Comment 4 Gaetano Mendola 2012-11-14 10:38:56 UTC
Same here with valgrind 3.8.1:

vex amd64->IR: unhandled instruction bytes: 0x48 0xF 0x5A 0x7 0x48 0xF 0x5A 0x4F
vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=0F
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
Comment 5 Griffin Myers 2013-09-09 17:12:21 UTC
Created attachment 82243 [details]
Fix relative to 3.8.1 release

The attached minor change to guest_amd64_toIR.c resolves this issue for me when running with IPP under valgrind 3.8.1.
Comment 6 Griffin Myers 2013-09-09 17:14:48 UTC
Created attachment 82244 [details]
Fix relative to current SVN HEAD (r2755)

And furthermore, here is a second patch which fixes this relative to the current SVN HEAD (r2755).  There is no difference between the two patches other than the relevant line numbers.
Comment 7 Patrick Noffke 2013-11-13 16:27:02 UTC
I have the exact same output as Gaetano reported in comment #4.  The patch from Griffin Myers works for me.
Comment 8 Mark Wielaard 2015-10-09 20:56:04 UTC
Created attachment 94921 [details]
redundantRexW testcase extension for cvtps2pd

I think ignoring the REX.W for cvtps2pd is correct. I cannot find anything that explains what it really means. Attached is an extension to the none/tests/amd64/redundantRexW testcase that seems to confirm it.
Comment 9 Mark Wielaard 2015-10-12 14:28:19 UTC
*** Bug 329245 has been marked as a duplicate of this bug. ***
Comment 10 Mark Wielaard 2015-10-12 14:32:23 UTC
VEX svn r3198
valgrind svn r15699