/wrkdirs/usr/ports/graphics/opencv/work/opencv-4.5.5/modules/core/include/opencv2/core/vsx_utils.hpp:352:12: warning: 'vec_permi' macro redefined [-Wmacro-redefined]
# define vec_permi(a, b, c) vec_xxpermdi(b, a, (3 ^ (((c) & 1) << 1 | (c) >> 1)))
^
/usr/lib/clang/13.0.0/include/altivec.h:13077:9: note: previous definition is here
#define vec_permi(__a, __b, __c) \
^
/wrkdirs/usr/ports/graphics/opencv/work/opencv-4.5.5/modules/core/include/opencv2/core/vsx_utils.hpp:370:25: error: redefinition of 'vec_promote'
VSX_FINLINE(vec_dword2) vec_promote(long long a, int b)
^
/usr/lib/clang/13.0.0/include/altivec.h:14604:1: note: previous definition is here
vec_promote(signed long long __a, int __b) {
^
/wrkdirs/usr/ports/graphics/opencv/work/opencv-4.5.5/modules/core/include/opencv2/core/vsx_utils.hpp:377:26: error: redefinition of 'vec_promote'
VSX_FINLINE(vec_udword2) vec_promote(unsigned long long a, int b)
^
/usr/lib/clang/13.0.0/include/altivec.h:14611:1: note: previous definition is here
vec_promote(unsigned long long __a, int __b) {
^
/wrkdirs/usr/ports/graphics/opencv/work/opencv-4.5.5/modules/core/include/opencv2/core/hal/intrin_vsx.hpp:1045:22: error: call to 'vec_rsqrt' is ambiguous
{ return v_float32x4(vec_rsqrt(x.val)); }
^~~~~~~~~
/usr/lib/clang/13.0.0/include/altivec.h:8472:34: note: candidate function
static vector float __ATTRS_o_ai vec_rsqrt(vector float __a) {
^
/wrkdirs/usr/ports/graphics/opencv/work/opencv-4.5.5/modules/core/include/opencv2/core/vsx_utils.hpp:362:29: note: candidate function
VSX_FINLINE(vec_float4) vec_rsqrt(const vec_float4& a)
^
/wrkdirs/usr/ports/graphics/opencv/work/opencv-4.5.5/modules/core/include/opencv2/core/hal/intrin_vsx.hpp:1047:22: error: call to 'vec_rsqrt' is ambiguous
{ return v_float64x2(vec_rsqrt(x.val)); }
^~~~~~~~~
/usr/lib/clang/13.0.0/include/altivec.h:8477:35: note: candidate function
static vector double __ATTRS_o_ai vec_rsqrt(vector double __a) {
^
/wrkdirs/usr/ports/graphics/opencv/work/opencv-4.5.5/modules/core/include/opencv2/core/vsx_utils.hpp:365:30: note: candidate function
VSX_FINLINE(vec_double2) vec_rsqrt(const vec_double2& a)
^
1 warning and 4 errors generated.
The specific functions were added to altivec.h in LLVM's 1ff93618e58df210def48d26878c20a1b414d900, c3da07d216dd20fbdb7302fd085c0a59e189ae3d and 10cc5bcd868c433f9a781aef82178b04e98bd098.
All classes are registered in the scope that corresponds to C++
namespace or exported class.
Example:
`cv::ml::Boost` is exported as `cv.ml.Boost`
`cv::SimpleBlobDetector::Params` is exported as
`cv.SimpleBlobDetector.Params`
For backward compatibility all classes are registered in the global
module with their mangling name containing scope information.
Example:
`cv::ml::Boost` has `cv.ml_Boost` alias to `cv.ml.Boost` type
* Fix wrong MSAN errors.
Because Fortran is called in Lapack, MSAN does not think the memory
has been written even though it is the case.
MSAN does no support well cross-language memory analysis.
* Make a dedicated check.
clang-cl defines both __clang__ and _MSC_VER, yet uses `#pragma GCC` to disable certain diagnostics.
At the time `-Wreturn-type-c-linkage` was reported by clang-cl.
This PR fixes this behavior by reordering defines.
- Add special case handling when submodule has the same name as parent
- `PyDict_SetItemString` doesn't steal reference, so reference count
should be explicitly decremented to transfer object life-time
ownership
- Add sanity checks for module registration input
* Fix compile against lapack-3.10.0
Fix compilation against lapack >= 3.9.1 and 3.10.0 while not breaking older versions
OpenCVFindLAPACK.cmake & CMakeLists.txt: determine OPENCV_USE_LAPACK_PREFIX from LAPACK_VERSION
hal_internal.cpp : Only apply LAPACK_FUNC to functions whose number of inputs depends on LAPACK_FORTRAN_STR_LEN in lapack >= 3.9.1
lapack_check.cpp : remove LAPACK_FUNC which is not OK as function are not used with input parameters (so lapack.h preprocessing of "LAPACK_xxxx(...)" is not applicable with lapack >= 3.9.1
If not removed lapack_check fails so LAPACK is deactivated in build (not want we want)
use OCV_ prefix and don't use Global, instead generate OCV_LAPACK_FUNC depending on CMake Conditions
Remove CONFIG from find_package(LAPACK) and use LAPACK_GLOBAL and LAPACK_NAME to figure out if using netlib's reference LAPACK implementation and how to #define OCV_LAPACK_FUNC(f)
* Fix typos and grammar in comments
Fow now, it is possible to define valid rectangle for which some
functions overflow (e.g. br(), ares() ...).
This patch fixes the intersection operator so that it works with
any rectangle.
1. Code uses PPC_FEATURE_HAS_VSX, but it's not checked similarly to
PPC_FEATURE2_ARCH_3_00 and PPC_FEATURE2_ARCH_3_00 for availability. FreeBSD has
those macros in machine/cpu.h, but I went with the way chosen for
PPC_FEATURE2_ARCH_3_00 and PPC_FEATURE2_ARCH_3_00. Other than that, FreeBSD also
has sys/auxv.h and that's where elf_aux_info() is defined.
2. getauxval() is actually Linux-only, but code checked for __unix__. It won't
work on all UNIX, so change it back to __linux__. Add another code variant
strictly for FreeBSD.
3. Update comment. This commit adds code for FreeBSD, but recently there
appeared support for powerpc64 in OpenBSD.
`PyObject*` to `std::vector<T>` conversion logic:
- If user passed Numpy Array
- If array is planar and T is a primitive type (doesn't require
constructor call) that matches with the element type of array, then
copy element one by one with the respect of the step between array
elements. If compiler is lucky (or brave enough) copy loop can be
vectorized.
For classes that require constructor calls this path is not
possible, because we can't begin an object lifetime without hacks.
- Otherwise fall-back to general case
- Otherwise - execute the general case:
If PyObject* corresponds to Sequence protocol - iterate over the
sequence elements and invoke the appropriate `pyopencv_to` function.
`std::vector<T>` to `PyObject*` conversion logic:
- If `std::vector<T>` is empty - return empty tuple.
- If `T` has a corresponding `Mat` `DataType` than return
Numpy array instance of the matching `dtype` e.g.
`std::vector<cv::Rect>` is returned as `np.ndarray` of shape `Nx4` and
`dtype=int`.
This branch helps to optimize further evaluations in user code.
- Otherwise - execute the general case:
Construct a tuple of length N = `std::vector::size` and insert
elements one by one.
Unnecessary functions were removed and code was rearranged to allow
compiler select the appropriate conversion function specialization.
Improves support for Unix non-Linux systems, including QNX
* Fixes#20395. Improves support for Unix non-Linux systems. Focus on QNX Neutrino.
Signed-off-by: promero <promero@mathworks.com>
* Update system.cpp
There can be an int overflow.
cv::norm( InputArray _src, int normType, InputArray _mask ) is fine,
not cv::norm( InputArray _src1, InputArray _src2, int normType, InputArray _mask ).
Improve performance on Arm64
* Improve performance on Apple silicon
This patch will
- Enable dot product intrinsics for macOS arm64 builds
- Enable for macOS arm64 builds
- Improve HAL primitives
- reduction (sum, min, max, sad)
- signmask
- mul_expand
- check_any / check_all
Results on a M1 Macbook Pro
* Updates to #20011 based on feedback
- Removes Apple Silicon specific workarounds
- Makes #ifdef sections smaller for v_mul_expand cases
- Moves dot product optimization to compiler optimization check
- Adds 4x4 matrix transpose optimization
* Remove dotprod and fix v_transpose
Based on the latest, we've removed dotprod entirely and will revisit in a future PR.
Added explicit cats with v_transpose4x4()
This should resolve all opens with this PR
* Remove commented out lines
Remove two extraneous comments
Also bring perf_imgproc CornerMinEigenVal accuracy requirements in line with
the test_imgproc accuracy requirements on that test and fix indentation on
the latter.
Partially addresses issue #9821
