https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100438
Filipe Brandenburger <filbranden at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |filbranden at gmail dot com
--- Comment #8 from Filipe Brandenburger <filbranden at gmail dot com> ---
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?
Thanks!
Filipe
