Why vectorscan require GCC9+ while hyperscan require only GCC4.8?

[leeyiw]

I'm compiling vectorscan with GCC6.5 and got this error:

[0m-- The C compiler identification is GNU 6.5.1
-- The CXX compiler identification is GNU 6.5.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /apsara/alicpp/built/gcc-6.5.1/gcc-6.5.1/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /apsara/alicpp/built/gcc-6.5.1/gcc-6.5.1/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test ARCH_X86_64
-- Performing Test ARCH_X86_64 - Failed
-- Performing Test ARCH_IA32
-- Performing Test ARCH_IA32 - Failed
-- Performing Test ARCH_AARCH64
-- Performing Test ARCH_AARCH64 - Success
-- Performing Test ARCH_ARM32
-- Performing Test ARCH_ARM32 - Failed
-- Performing Test ARCH_PPC64EL
-- Performing Test ARCH_PPC64EL - Failed
-- Default build type 'Release with debug info'
-- using release build
-- Boost version: 1.64.0
-- Found PythonInterp: /usr/bin/python (found version "2.7.5")
-- Build date: 2022-06-01
-- Building static libraries
-- gcc version 6.5.1
�[91mCMake Warning at CMakeLists.txt:187 (message):
Something went wrong determining gcc tune: -mtune=ARCH not valid, falling
back to -mtune=native
�[0m-- ARCH_C_FLAGS   :
-- ARCH_CXX_FLAGS :
-- g++ version 6.5.1
�[91mCMake Error at CMakeLists.txt:273 (message):
A minimum of g++ 9 is required for C++17 support
�[0m-- Configuring incomplete, errors occurred!

it's weird while hyperscan is supporting GCC4.8 and vectorscan raise version requirements to GCC9+ with this commit.

Anyone would explain this?

[markos]

For one thing, we require proper Arm NEON and Power VSX intrinsics, which were not working properly in such an old gcc version and secondly we started using some C++ constructs that are C++17 only. The requirement is not going to go away. Perhaps, we might allow fallback to C++14 but at worst we will require gcc 8. gcc 4.8 is out of the question. Closing this as a non-issue.