C++ warnings being treated as errors with GCC 12.3.0

[boegel]

Issue Report

Please describe the issue:

Multiple compiler warnings being treated as errors are resulting in a failure to build from source, unless -Wno-error is used:

/tmp/easybuild_build/dorado/0.6.1/foss-2023a-CUDA-12.1.1/dorado/dorado/utils/tensor_utils.cpp:18:6: error: void {anonymous}::convert_f32_to_f16_impl(c10::Half*, const float*, std::size_t) defined but not used [-Werror=unused-function]
   18 | void convert_f32_to_f16_impl(c10::Half* const dest, const float* const src, std::size_t count) {
      |      ^~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors

In function std::_Require<std::__not_<std::__is_tuple_like<_Tp> >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&, _Tp&) [with _Tp = char],
    inlined from void std::iter_swap(_ForwardIterator1, _ForwardIterator2) [with _ForwardIterator1 = char*; _ForwardIterator2 = char*] at /software/GCCcore/12.3.0/include/c++/12.3.0/bits/stl_algobase.h:182:11,
    inlined from void std::__reverse(_RandomAccessIterator, _RandomAccessIterator, random_access_iterator_tag) [with _RandomAccessIterator = char*] at /software/GCCcore/12.3.0/include/c++/12.3.0/bits/stl_algo.h:1107:18,
    inlined from void std::reverse(_BIter, _BIter) [with _BIter = char*] at /software/GCCcore/12.3.0/include/c++/12.3.0/bits/stl_algo.h:1134:21,
    inlined from void date::detail::read(std::basic_istream<_CharT, _Traits>&, int, Args&& ...) [with CharT = char; Traits = std::char_traits<char>; Args = {char&, const char&}] at /tmp/easybuild_build/dorado/0.6.1/foss-2023a-CUDA-12.1.1/dorado/dorado/3rdparty/date/include/date/date.h:6527:21,
    inlined from void date::detail::read(std::basic_istream<_CharT, _Traits>&, CharT, Args&& ...) [with CharT = char; Traits = std::char_traits<char>; Args = {int&, char&, const char&}] at /tmp/easybuild_build/dorado/0.6.1/foss-2023a-CUDA-12.1.1/dorado/dorado/3rdparty/date/include/date/date.h:6488:9:
/software/GCCcore/12.3.0/include/c++/12.3.0/bits/move.h:205:11: error: writing 16 bytes into a region of size 11 [-Werror=stringop-overflow=]
  205 |       __a = _GLIBCXX_MOVE(__b);
      |           ^

...
/software/GCCcore/12.3.0/include/c++/12.3.0/bits/move.h:205:11: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=]
  205 |       __a = _GLIBCXX_MOVE(__b);
      |

In lambda function,
    inlined from std::vector<dorado::splitter::EdistResult> dorado::splitter::myers_align(std::string_view, std::string_view, std::size_t) at /tmp/easybuild_build/dorado/0.6.1/foss-2023a-CUDA-12.1.1/dorado/dorado/splitter/myers.cpp:135:18:
/tmp/easybuild_build/dorado/0.6.1/foss-2023a-CUDA-12.1.1/dorado/dorado/splitter/myers.cpp:99:41: error: *(long unsigned int*)((char*)&current_range_end + offsetof(std::optional<long unsigned int>,std::optional<long unsigned int>::<unnamed>.std::_Optional_base<long unsigned int, true, true>::<unnamed>)) may be used uninitialized [-Werror=maybe-uninitialized]
   99 |                         ranges.push_back(
      |                         ~~~~~~~~~~~~~~~~^
  100 |                                 {min_match_start + edlib_result.startLocations[i], end, edist});
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Steps to reproduce the issue:

Build from source with GCC 12.3.0 (with EasyBuild 4.9.1), configure with $CXXFLAGS set to "-O2 -ftree-vectorize -march=native -fno-math-errno".

Problem can be fixed by also adding -Wno-error to $CXXFLAGS

Run environment:

• Dorado version: 0.6.1
• Dorado command: N/A
• Operating system: RHEL 8.8 + GCC 12.3.0 (installed via EasyBuild)
• Hardware (CPUs, Memory, GPUs): Intel Xeon Gold 6240 (Cascade Lake), 2x 18 cores, cpuset with 8 cores and ~27GB of available memory
• Source data type: N/A
• Source data location (on device or networked drive - NFS, etc.): N/A (local disk)
• Details about data (flow cell, kit, read lengths, number of reads, total dataset size in MB/GB/TB): N/A
• Dataset to reproduce, if applicable (small subset of data to share as a pod5 to reproduce the issue): N/A

Logs

• Please provide output trace of dorado (run dorado with -v, or -vv on a small subset): N/A

[malton-ont]

Hi @boegel,

Thanks for raising this. We currently build using gcc9, so I'm not very surprised newer version have some quirks. Some of these we can fix in a future release.

What is the reason you're changing the CXXFLAGS? That seems to have triggered an error in the date library submodule (specifically -march=native is causing the issue), which will need addressing by https://github.com/HowardHinnant/date.

[boegel]

@malton-ont -march=native is important to obtain a build that is optimized for the CPUs on which the software will run, we build pretty much our full software stack with it in EasyBuild