vfma.f32 q13, q12, q5 will show the bug vfmaq_f32() intrinsic will also show it.
When reporting unsupported instructions please include the error message from valgrind as it includes important information that is useful for fixing the bug.
Sorry, I had already changed the code to remove the vfma.f32 instructions when I posted the bug. I put a couple back and ran it for you. ==2033== Callgrind, a call-graph generating cache profiler ==2033== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al. ==2033== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==2033== Command: ./dronose /mnt/SDCARD/data/frames bb.txt ==2033== ==2033== For interactive control, run 'callgrind_control -h'. type = bb roi_xmin = 404 roi_ymin = 103 roi_xmax = 457 roi_ymax = 184 nfrm = 260 disInstr(arm): unhandled instruction: 0xF20AECFA cond=15(0xF) 27:20=32(0x20) 4:4=1 3:0=10(0xA) ==2033== valgrind: Unrecognised instruction at address 0x84494. ==2033== at 0x84494: ExtractBestGradientARM_3(Gradient*, _IplImage*, _IplImage*, int, int) (fhog.cpp:486) ==2033== by 0x8508F: getFeatureMaps(_IplImage const*, int, CvLSVMFeatureMapCaskade**) (fhog.cpp:619) ==2033== by 0x777D7: KCFTracker::getFeatures(cv::Mat const&, bool, float, KCFTracker::SizePatch&) (kcftracker.cpp:616) ==2033== by 0x7C67B: KCFTracker::init(cv::Rect_<int> const&, cv::Mat) (kcftracker.cpp:121) ==2033== by 0x73613: AltumTracker::setRoi(cv::Rect_<int>, cv::Mat) (altumtracker.cpp:97) ==2033== by 0x6B087: selector::setRoiRunTracker(int, int, int, int) (dronose.cpp:88) ==2033== by 0x694BF: main (dronose.cpp:320) ==2033== Your program just tried to execute an instruction that Valgrind ==2033== did not recognise. There are two possible reasons for this. ==2033== 1. Your program has a bug and erroneously jumped to a non-code ==2033== location. If you are running Memcheck and you just saw a ==2033== warning about a bad jump, it's probably your program's fault. ==2033== 2. The instruction is legitimate but Valgrind doesn't handle it, ==2033== i.e. it's Valgrind's fault. If you think this is the case or ==2033== you are not sure, please let us know and we'll try to fix it. ==2033== Either way, Valgrind will now raise a SIGILL signal which will ==2033== probably kill your program. ==2033== ==2033== Process terminating with default action of signal 4 (SIGILL) ==2033== Illegal opcode at address 0x84494 ==2033== at 0x84494: ExtractBestGradientARM_3(Gradient*, _IplImage*, _IplImage*, int, int) (fhog.cpp:486) ==2033== by 0x8508F: getFeatureMaps(_IplImage const*, int, CvLSVMFeatureMapCaskade**) (fhog.cpp:619) ==2033== by 0x777D7: KCFTracker::getFeatures(cv::Mat const&, bool, float, KCFTracker::SizePatch&) (kcftracker.cpp:616) ==2033== by 0x7C67B: KCFTracker::init(cv::Rect_<int> const&, cv::Mat) (kcftracker.cpp:121) ==2033== by 0x73613: AltumTracker::setRoi(cv::Rect_<int>, cv::Mat) (altumtracker.cpp:97) ==2033== by 0x6B087: selector::setRoiRunTracker(int, int, int, int) (dronose.cpp:88) ==2033== by 0x694BF: main (dronose.cpp:320) ==2033== ==2033== Events : Ir ==2033== Collected : 55834099 ==2033== ==2033== I refs: 55,834,099 Illegal instruction
The offending lines of code in GCC inline asm look like this: "vfma.f32 q7, q13, q13 \n" "vfma.f32 q8, q14, q14 \n" "vfma.f32 q9, q15, q15 \n" It's dying on the first one.
I also met this issue. I'm using Cortex A35 ARM core (ARMv8) and running code built as 32bit. The instruction unhandled is: 0xF240ACF4 vfma.f32 q13, q8, q10 The full log is as below: disInstr(arm): unhandled instruction: 0xF240ACF4 cond=15(0xF) 27:20=36(0x24) 4:4=1 3:0=4(0x4) ==930== valgrind: Unrecognised instruction at address 0x56772a0. ==930== at 0x56772A0: ??? (in /usr/lib/libxxxx.so) ==930== Your program just tried to execute an instruction that Valgrind ==930== did not recognise. There are two possible reasons for this. ==930== 1. Your program has a bug and erroneously jumped to a non-code ==930== location. If you are running Memcheck and you just saw a ==930== warning about a bad jump, it's probably your program's fault. ==930== 2. The instruction is legitimate but Valgrind doesn't handle it, ==930== i.e. it's Valgrind's fault. If you think this is the case or ==930== you are not sure, please let us know and we'll try to fix it. ==930== Either way, Valgrind will now raise a SIGILL signal which will ==930== probably kill your program. disInstr(arm): unhandled instruction: 0xF240ACF4 cond=15(0xF) 27:20=36(0x24) 4:4=1 3:0=4(0x4) ==930== valgrind: Unrecognised instruction at address 0x56772a0. ==930== at 0x56772A0: ??? (in /usr/lib/libxxxx.so) ==930== Your program just tried to execute an instruction that Valgrind ==930== did not recognise. There are two possible reasons for this. ==930== 1. Your program has a bug and erroneously jumped to a non-code ==930== location. If you are running Memcheck and you just saw a ==930== warning about a bad jump, it's probably your program's fault. ==930== 2. The instruction is legitimate but Valgrind doesn't handle it, ==930== i.e. it's Valgrind's fault. If you think this is the case or ==930== you are not sure, please let us know and we'll try to fix it. ==930== Either way, Valgrind will now raise a SIGILL signal which will ==930== probably kill your program.