Question

使用GCC 5.1.0下的OpenCL C++ Wrapper 1.2.7会出现错误

/usr/include/CL/cl.hpp:2442:29: error: cl::Context::default_initialized_ declared weak after being used
     static std::atomic<int> default_initialized_;

这是相应位置的代码清单：

class Context 
    : public detail::Wrapper<cl_context>
{
private:

#ifdef CL_HPP_CPP11_ATOMICS_SUPPORTED 
    static std::atomic<int> default_initialized_; // <- line 2442
#else // !CL_HPP_CPP11_ATOMICS_SUPPORTED
    static volatile int default_initialized_;
#endif // !CL_HPP_CPP11_ATOMICS_SUPPORTED

我只能在GCC及其source code的一些补丁中找到此错误消息，并且没有解释它意味着什么以及如何避免它。

我认为这是指弱符号~~，但错误似乎是针对在此上下文中没有意义的函数设计的~~（基于旧的错误消息＆＃34;在内联后声明被称为＆＃34;）。

对我来说，这归结为以下问题：

谁是罪魁祸首？我，OpenCL包装器还是GCC？

和

如何避免此错误？

MWE

#include <CL/cl.hpp>    
int main() {}

创建此示例时，我注意到只有在使用未定义的行为清理程序（-fsanitize=undefined）时才会出现错误。

使用预C ++ 11时，另一个成员会出现问题，但错误消息保持不变。

附加上下文

我浏览了cl.hpp的代码，发现了可能的错误来源。

cl::Context和cl::CommandQueue都以

开头

private:
#ifdef CL_HPP_CPP11_ATOMICS_SUPPORTED
    static std::atomic<int> default_initialized_;
#else // !CL_HPP_CPP11_ATOMICS_SUPPORTED
    static volatile int default_initialized_;
#endif // !CL_HPP_CPP11_ATOMICS_SUPPORTED
    static CommandQueue default_;
    static volatile cl_int default_error_;

以后会有例如。

#ifdef _WIN32
#ifdef CL_HPP_CPP11_ATOMICS_SUPPORTED
__declspec(selectany) std::atomic<int> Context::default_initialized_;
#else // !CL_HPP_CPP11_ATOMICS_SUPPORTED
__declspec(selectany) volatile int Context::default_initialized_ = __DEFAULT_NOT_INITIALIZED;
#endif // !CL_HPP_CPP11_ATOMICS_SUPPORTED
__declspec(selectany) Context Context::default_;
__declspec(selectany) volatile cl_int Context::default_error_ = CL_SUCCESS;
#else // !_WIN32
#ifdef CL_HPP_CPP11_ATOMICS_SUPPORTED
__attribute__((weak)) std::atomic<int> Context::default_initialized_;
#else // !CL_HPP_CPP11_ATOMICS_SUPPORTED
__attribute__((weak)) volatile int Context::default_initialized_ = __DEFAULT_NOT_INITIALIZED;
#endif // !CL_HPP_CPP11_ATOMICS_SUPPORTED
__attribute__((weak)) Context Context::default_;
__attribute__((weak)) volatile cl_int Context::default_error_ = CL_SUCCESS;
#endif // !_WIN32

显然，在没有这个属性的声明之后的定义中添加了弱属性。

因此，我现在的问题是：这是库代码的缺点还是UB消毒剂过于敏感？

避免使用静态成员＆＃34;在使用后声明为弱＆＃34;错误

MWE

附加上下文

0 个答案: