Old compiler support

[krasznaa]

While trying to see that I could build/use the core library successfully on my Raspberry Pi-s, I came across something curious. Quite unexpectedly GCC 6.3.0 that comes with Raspbian 9, does manage to build the project...

[bash][rberry-3b]:VecMem > /opt/cmake/3.18.4/armv7l-raspbian9-gcc63-opt/bin/cmake -DCMAKE_BUILD_TYPE=Release -S vecmem -B build
-- The CXX compiler identification is GNU 6.3.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for a CUDA compiler
-- Looking for a CUDA compiler - NOTFOUND
-- Looking for a HIP compiler
-- Looking for a HIP compiler - NOTFOUND
-- Looking for a SYCL compiler
-- Looking for a SYCL compiler - NOTFOUND
-- Performing Test VECMEM_HAVE_PMR_MEMORY_RESOURCE
-- Performing Test VECMEM_HAVE_PMR_MEMORY_RESOURCE - Failed
-- Performing Test VECMEM_HAVE_EXPERIMENTAL_PMR_MEMORY_RESOURCE
-- Performing Test VECMEM_HAVE_EXPERIMENTAL_PMR_MEMORY_RESOURCE - Success
-- Using memory resource types from the std::experimental::pmr namespace
-- Performing Test VECMEM_HAVE_DEFAULT_RESOURCE
-- Performing Test VECMEM_HAVE_DEFAULT_RESOURCE - Success
-- Could NOT find GTest (missing: GTEST_LIBRARY GTEST_INCLUDE_DIR GTEST_MAIN_LIBRARY) 
-- Building GoogleTest as part of the project
-- The C compiler identification is GNU 6.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Python: /usr/bin/python3.5 (found version "3.5.3") found components: Interpreter 
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Configuring done
-- Generating done
-- Build files have been written to: /home/krasznaa/ATLAS/VecMem/build
[bash][rberry-3b]:VecMem >

The experimental support for the memory resources was ported all the way back into this compiler. 😲 I only had to make these changes to make the code work:

diff --git a/core/include/vecmem/memory/memory_resource.hpp b/core/include/vecmem/memory/memory_resource.hpp
index 0a76c7e..904f506 100644
--- a/core/include/vecmem/memory/memory_resource.hpp
+++ b/core/include/vecmem/memory/memory_resource.hpp
@@ -7,15 +7,6 @@
 
 #pragma once
 
-// This header can only be used in C++17 mode. So "device compilers" that
-// can't use C++17, must not see it. Which in practically all cases should
-// "just" be a question of code organisation.
-#if __cplusplus < 201700L
-#error \
-    "This header can only be used in C++17 mode. " \
-         "Ideally it should only be used by the \"host compiler\"."
-#endif  // < C++17
-
 /*
  * The purpose of this file is to provide uniform access (on a source-code
  * level) to the memory_resource type from the standard library. These are
diff --git a/core/include/vecmem/memory/polymorphic_allocator.hpp b/core/include/vecmem/memory/polymorphic_allocator.hpp
index 1946c3f..c4f4277 100644
--- a/core/include/vecmem/memory/polymorphic_allocator.hpp
+++ b/core/include/vecmem/memory/polymorphic_allocator.hpp
@@ -7,15 +7,6 @@
 
 #pragma once
 
-// This header can only be used in C++17 mode. So "device compilers" that
-// can't use C++17, must not see it. Which in practically all cases should
-// "just" be a question of code organisation.
-#if __cplusplus < 201700L
-#error \
-    "This header can only be used in C++17 mode. " \
-         "Ideally it should only be used by the \"host compiler\"."
-#endif  // < C++17
-
 /*
  * The purpose of this file is to provide uniform access (on a source-code
  * level) to the polymorphic_allocator type from the standard library. These are
diff --git a/tests/core/test_core_jagged_vector_view.cpp b/tests/core/test_core_jagged_vector_view.cpp
index 1647081..451799f 100644
--- a/tests/core/test_core_jagged_vector_view.cpp
+++ b/tests/core/test_core_jagged_vector_view.cpp
@@ -141,7 +141,7 @@ TEST_F(core_jagged_vector_view_test, filter) {
     copy.setup(output_data);
 
     // Fill the jagged vector buffer with just the odd elements.
-    vecmem::jagged_device_vector device_vec(output_data);
+    vecmem::jagged_device_vector<int> device_vec(output_data);
     for (std::size_t i = 0; i < m_vec.size(); ++i) {
         for (std::size_t j = 0; j < m_vec.at(i).size(); ++j) {
             if ((m_vec[i][j] % 2) != 0) {

I.e. I disabled the C++17 check temporarily, and I had to fix a test that was mistakenly using template type deduction without me realising. At this point the compilation still throws a bunch of warnings about stuff that the compiler does not quite understand (for instance [[maybe_unused]]), but the build does succeed. And the test runs successfully as well.

This all made me wonder: What would be the best way to formulate our requirements in the end? Since it seems that C++17 is not actually a strict requirement after all. 🤔

[krasznaa]

Pinging @stephenswat and @paulgessinger, just to make sure they see it. 😉

[paulgessinger]

I don't know honestly. I'm not super happy with using stuff in experimental anyway. I don't see a good argument dropping C++17 for this.

[krasznaa]

To make it clear, it was really just something I wondered about. I was trying the build on Raspbian 9 with many different compilers, and was astounded to see that I could make even GCC 6.3 work. (With GCC 8+ the project works on ARM out of the box.)

As a bit of a back-story: For a moment I thought that we may need to explicitly make use of libatomic on ARM, similar to root-project/root#4561. But then had to realise that in the host code we don't actually use any atomic operations at the moment... So to make the bootup of my Raspberry Pi worthwhile, I thought I would at least share this finding with you guys. 😛

[stephenswat]

I have to say I am experiencing a strong feeling of déjà-vu with this conversation! 😄