facebook/folly

Build failure with GCC 14 (drop builtin __type_pack_element usage)

thesamesam opened this issue · 2 comments

With folly-2023.04.10.00 with GCC 14.0.0 20230423, I get this failure:

FAILED: CMakeFiles/folly_base.dir/folly/Unicode.cpp.o 
/usr/bin/aarch64-unknown-linux-gnu-g++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_CONTEXT_DYN_LINK -DBOOST_CONTEXT_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_NO_LIB -DBOOST_REGEX_DYN_LINK -DBOOST_REGEX_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -DFMT_SHARED -DFOLLY_XLOG_STRIP_PREFIXES=\"/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00:/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00_build\" -DGFLAGS_IS_A_DLL=0 -D_GNU_SOURCE -D_REENTRANT -I/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00 -I/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00_build -I/usr/include/libiberty  -O2 -pipe -mcpu=native -fPIC -fcoroutines -g -std=gnu++1z -finput-charset=UTF-8 -fsigned-char -Wall -Wno-deprecated -Wno-deprecated-declarations -Wno-sign-compare -Wno-unused -Wuninitialized -Wunused-label -Wunused-result -Wshadow-compatible-local -Wno-noexcept-type -faligned-new -fopenmp -std=gnu++17 -MD -MT CMakeFiles/folly_base.dir/folly/Unicode.cpp.o -MF CMakeFiles/folly_base.dir/folly/Unicode.cpp.o.d -o CMakeFiles/folly_base.dir/folly/Unicode.cpp.o -c /var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Unicode.cpp
In file included from /var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Unicode.cpp:21:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h: In instantiation of ‘folly::detail::LastElement<Ts ...>& folly::detail::getLastElement(const Ts& ...) [with Ts = {char [26], unsigned int, char [4], unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*}]’:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:312:27: error: use of built-in trait ‘__type_pack_element<sizeof ... (T ...) - 1, T ...>’ in function signature; use library traits instead
  312 | const LastElement<Ts...>& getLastElement(const Ts&... ts) {
      |                           ^~~~~~~~~~~~~~
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h: In instantiation of ‘folly::detail::LastElement<Ts ...>& folly::detail::getLastElement(const Ts& ...) [with Ts = {char [26], unsigned int, char [6], unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*}]’:
/var/tmp/portage/dev-cpp/folly-2023.04.10.00/work/folly-2023.04.10.00/folly/Conv.h:312:27: error: use of built-in trait ‘__type_pack_element<sizeof ... (T ...) - 1, T ...>’ in function signature; use library traits instead
[...]

I initially reported this to GCC at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109625, but the conclusion is:

(In reply to Andrew Pinski from comment #3)

Folly should not use internal functions which is not designed for other than
libstdc++.

The function wasn't designed for libstdc++, Clang had it first.

But Folly shouldn't assume that non-standard extensions have a consistent/portable mangling suitable for use in APIs. In this case, it can't be mangled at all.

It looks like the block at https://github.com/facebook/folly/blob/main/folly/Traits.h#L964-L974 needs to be simplified to just drop poking around in internals - i.e. always take the second branch.

cc @ArsenArsen

It's fine to use the built-in, just not in a context where it becomes part of a mangled name. So it's fine if it's used like so:

template <std::size_t I, typename... Ts>
struct type_pack_element { using type = __type_pack_element<I, Ts...>; };
template <std::size_t I, typename... Ts>
using type_pack_element_t = typename type_pack_element<I, Ts...>::type;

This has a slight cost, as you still need to instantiate a single class template, but will still be cheaper to evaluate than the fallback.

Thanks!