[SYCL] new warnings in gcc 8 and 9 (buildbot configure/compile)

[bd4]

Using buildbot configure/compile scripts, in release mode with no other options (in particular no cuda). I have Manjaro linux, arch based, default compiler is g++ 9.3.0. I get the following error. Will try again with g++-8 (and -7 if that fails), I suspect this is an issue due to differing warning/error handling in 9.

FAILED: tools/sycl/source/CMakeFiles/sycl_object.dir/detail/error_handling/enqueue_kernel.cpp.o 
/usr/bin/c++  -DXPTI_ENABLE_INSTRUMENTATION -DXPTI_STATIC_LIBRARY -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/sycl/source -I/home/bda/isycl/llvm/sycl/source -I/usr/include/libxml2 -Iinclude -I/home/bda/isycl/llvm/llvm/include -I/home/bda/isycl/llvm/xpti/include -I/home/bda/isycl/llvm/sycl/include -Itools/sycl/OpenCL/inc -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-redundant-move -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -Wextra -Wno-deprecated-declarations -Werror -O3    -UNDEBUG -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -MD -MT tools/sycl/source/CMakeFiles/sycl_object.dir/detail/error_handling/enqueue_kernel.cpp.o -MF tools/sycl/source/CMakeFiles/sycl_object.dir/detail/error_handling/enqueue_kernel.cpp.o.d -o tools/sycl/source/CMakeFiles/sycl_object.dir/detail/error_handling/enqueue_kernel.cpp.o -c /home/bda/isycl/llvm/sycl/source/detail/error_handling/enqueue_kernel.cpp
In file included from /home/bda/isycl/llvm/sycl/include/CL/sycl/types.hpp:53,
                 from /home/bda/isycl/llvm/sycl/include/CL/sycl/intel/sub_group.hpp:22,
                 from /home/bda/isycl/llvm/sycl/include/CL/sycl/nd_item.hpp:17,
                 from /home/bda/isycl/llvm/sycl/include/CL/sycl/detail/cg.hpp:22,
                 from /home/bda/isycl/llvm/sycl/source/detail/error_handling/error_handling.hpp:11,
                 from /home/bda/isycl/llvm/sycl/source/detail/error_handling/enqueue_kernel.cpp:13:
/home/bda/isycl/llvm/sycl/include/CL/sycl/multi_ptr.hpp:520:3: error: converting ‘cl::sycl::multi_ptr<const void, Space>’ to the same type will never use a type conversion operator [-Werror=class-conversion]
  520 |   operator multi_ptr<const void, Space>() const {
      |   ^~~~~~~~
cc1plus: all warnings being treated as errors

[bd4]

With g++ 8.4.0, I get a different error:

FAILED: tools/sycl/source/CMakeFiles/sycl_object.dir/detail/config.cpp.o 
/usr/bin/g++-8  -DXPTI_ENABLE_INSTRUMENTATION -DXPTI_STATIC_LIBRARY -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/sycl/source -I/home/bda/isycl/llvm/sycl/source -I/usr/include/libxml2 -Iinclude -I/home/bda/isycl/llvm/llvm/include -I/home/bda/isycl/llvm/xpti/include -I/home/bda/isycl/llvm/sycl/include -Itools/sycl/OpenCL/inc -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -Wextra -Wno-deprecated-declarations -Werror -O3    -UNDEBUG -fvisibility=hidden -fvisibility-inlines-hidden -std=c++11 -MD -MT tools/sycl/source/CMakeFiles/sycl_object.dir/detail/config.cpp.o -MF tools/sycl/source/CMakeFiles/sycl_object.dir/detail/config.cpp.o.d -o tools/sycl/source/CMakeFiles/sycl_object.dir/detail/config.cpp.o -c /home/bda/isycl/llvm/sycl/source/detail/config.cpp
In function ‘void cl::sycl::detail::initValue(const char*, const char*)’,
    inlined from ‘void cl::sycl::detail::readConfig()’ at /home/bda/isycl/llvm/sycl/source/detail/config.cpp:96:16:
/home/bda/isycl/llvm/sycl/source/detail/config.cpp:42:12: error: ‘char* strncpy(char*, const char*, size_t)’ output may be truncated copying 1 byte from a string of length 255 [-Werror=stringop-truncation]
     strncpy(SYCLConfigBase<Name>::MStorage, Value, MaxSize);                   \
     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bda/isycl/llvm/sycl/source/detail/config.def:14:1: note: in expansion of macro ‘CONFIG’
 CONFIG(SYCL_DISABLE_EXECUTION_GRAPH_CLEANUP, 1, __SYCL_DISABLE_EXECUTION_GRAPH_CLEANUP)
 ^~~~~~
/home/bda/isycl/llvm/sycl/source/detail/config.cpp:42:12: error: ‘char* strncpy(char*, const char*, size_t)’ output may be truncated copying 32 bytes from a string of length 255 [-Werror=stringop-truncation]
     strncpy(SYCLConfigBase<Name>::MStorage, Value, MaxSize);                   \
     ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/bda/isycl/llvm/sycl/source/detail/config.def:13:1: note: in expansion of macro ‘CONFIG’
 CONFIG(SYCL_PRINT_EXECUTION_GRAPH, 32, __SYCL_PRINT_EXECUTION_GRAPH)
 ^~~~~~
cc1plus: all warnings being treated as errors

trying with 7.5.0

[bader]

@bd4, thank you for reporting these issues.
All these seems like a new warnings, which are treated as errors for the library project.
You can configure the build system to keep them as warnings using --no-werror option for configure.py script.

[bd4]

Thanks @bader, I renamed the issue to better reflect the cause. With the --no-werror option I guess this is not high priority, but perhaps worth mentioning that it's likely required for gcc > 7 in the getting started doc (I will work on a PR for this). With gcc 7.5.0, I am able to build without using the --no-werror.

[bader]

I think we should integrate gcc > 7 into CI process to avoid these types of issues.

Another proposal was to enforce -Werror by CI, but don't enable it by default, so users compiling with non-tested gcc version won't be impacted.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be automatically closed in 30 days.

[alexbatashev]

I think this is resolved now. Please, re-open if you disagree.