https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Filipe Brandenburger from comment #8)
> We encountered an issue due to the introduction of the `_serialize()` define
> in the build of the fbthrift package on GCC 11 (Fedora 34/35.)
>
> The error we get is coming from Cython code in a *.pyx file, which gets
> compiled to *.cpp and then compiled. Note that the name `_serialize` in this
> context is coming from Python code conventions, where this particular name
> is the most appropriate for its particular situation (the `_` indicating a
> protected method.)
>
> Also interesting is that the error we're seeing is actually in a method
> *call* and not even a function definition!
>
> Backtrace here:
>
> ```
> /builddir/build/BUILD/fbthrift-2021.06.28.00/x86_64-redhat-linux-gnu/thrift/
> lib/py3/cybld/thrift/py3/serializer.cpp:3482:154: error: macro "_serialize"
> passed 2 arguments, but takes just 0
> 3482 | __pyx_t_1 = ((PyObject *)((struct
> __pyx_vtabstruct_6thrift_3py3_5types_Struct
> *)__pyx_v_cy_struct->__pyx_vtab)->_serialize(__pyx_v_cy_struct, __pyx_t_5));
> if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 30, __pyx_L1_error)
> |
> ^
> In file included from
> /usr/lib/gcc/x86_64-redhat-linux/11/include/x86gprintrin.h:71,
> from
> /usr/lib/gcc/x86_64-redhat-linux/11/include/immintrin.h:27,
> from /usr/include/folly/container/detail/F14Table.h:74,
> from /usr/include/folly/container/detail/F14Policy.h:28,
> from /usr/include/folly/container/F14Map.h:42,
> from /usr/include/folly/io/async/Request.h:26,
> from /usr/include/folly/io/async/AsyncTimeout.h:23,
> from /usr/include/folly/io/async/HHWheelTimer.h:28,
> from /usr/include/folly/fibers/Baton.h:24,
> from /usr/include/folly/futures/Future.h:36,
> from
> /builddir/build/BUILD/fbthrift-2021.06.28.00/x86_64-redhat-linux-gnu/thrift/
> lib/py3/cybld/thrift/py3/serializer.cpp:645:
> /usr/lib/gcc/x86_64-redhat-linux/11/include/serializeintrin.h:37: note:
> macro "_serialize" defined here
> 37 | #define _serialize() __builtin_ia32_serialize ()
> |
> ```
>
> This is coming from the F14Map.h header from folly, which defines a map
> container type. That header file includes intrinsics in order to use a
> __m128i type definition.
>
> It's very unfortunate that intrinsics produce this kind of namespace
> pollution and that this particular one was defined with a name that's not
> uncommon enough not to cause real world problems.
>
> At the very least, can this particular case be changed from a `#define` to a
> `static inline void _serialize() { __builtin_ia32_serialize(); }` so that it
> only clashes with a `_serialize()` name defined in the top-level?
>
> For C++ code, would it be possible to have a C++ version of intrinsics
> headers that would define them inside a C++ namespace, so that it would be
> easy to introduce new intrinsics without further polluting the main
> namespace?
Please try:
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576603.html
on GCC master branch. I can create a backport branch for GCC 11 if needed.
