Move some static functions into the FarnebackOpticalFlow class as well,
so they can access these new class variables.
oclMat objects cannot be declared statically, because their destructor
depends on the statically defined __module variable from cl_context.cpp.
Since statically defined variables in separate compilation units have
an undefined destruction order there is always the possibility the
__module will be destructed before an oclMat object, which results
in a segfault.
gauss_w_lut is a statically defined variable of type oclMat. The oclMat
destructor calls openCLFree() which via getInitializationMutex() accesses
the __module variable which has been statically defined in cl_context.cpp
Since the destruction order of statically defined variables in different
compilation units is undefined, it is possible that __module will
be destructed before gauss_w_lut, which would result in a segfault when
getInitializationMutex() is called while destructing gauss_w_lut.
In order to avoid this issue, we need to make gauss_w_lut a private
member of the HOGDescriptors class so we know it will be destroyed
before __module.
ContextImpl::currentContext contains a reference to one of the
DeviceInfoImpl objects from:
static std::vector<DeviceInfoImpl> global_devices;
ContextImpl::currentContext is destroyed in the destructor
for the statically defined object __module, and relies on its
DeviceInfoImpl reference to query some hardware features while
being destroyed.
This means that we need to ensure that the global_devices vector is
destroyed affter __module, otherwise ContextImpl::currentContext's
DeviceInfoImpl reference will no longer be valid when __module is
destroyed.
Since these variables are all confined to a single compilation unit,
they will be destruct from bottom to top, so we need to make sure
that __module is the bottom definition so it can be destroyed first.
In C99 'inline' is not a hint to the compiler to inline the function,
it is an attribute that affects the linkage of the function. 'inline'
functions are required to have a definition in a different compiliation
unit, so compilers are free to delete 'inline' functions if they want to.
This issue can be seen in Clang when compiling at -O0. Clang
will sometimes delete 'inline' functions which creates an invalid
program.
Issue 3746: http://code.opencv.org/issues/3746
The LLVM/Clang 3.3 has a bug when compile a cl kernel with
assignment of a scalar to a vector data type. This patch
could work around this bug.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
