https://bugs.kde.org/show_bug.cgi?id=487993
--- Comment #5 from Paul Floyd <pjfl...@wanadoo.fr> --- I also get the assert on Fedora 40. As a workaround you can use "--alignment=16". However, I still don't quite understand what is happening. The operator new that gets called is just plain bog standard operator new(size_t) - not the aligned overload. That means Eigen::Affine3d doesn't have any alignment specifier. Operator new just calls malloc. GNU libc has a complicated way of setting the base alignment if malloc. https://elixir.bootlin.com/glibc/glibc-2.39/source/sysdeps/generic/malloc-alignment.h #define MALLOC_ALIGNMENT (2 * SIZE_SZ < __alignof__ (long double) \ ? __alignof__ (long double) : 2 * SIZE_SZ) long double is peculiar on x86. It's 10 bytes, its sizeof is 12 but its alignof is 4. SIZE_SZ is sizof size_t, 4. 2*SIZE_SZ is not less than alignof long double (4) so MALLOC_ALIGNMENT is 2*SIZE_SZ, or 8. That is the same as what Valgrind uses. The assert fires here │ 101 template <typename T, int Size, int MatrixOrArrayOptions> │ 102 struct plain_array<T, Size, MatrixOrArrayOptions, 16> │ 103 { │ 104 EIGEN_ALIGN_TO_BOUNDARY(16) T array[Size]; │ 105 │ 106 EIGEN_DEVICE_FUNC │ 107 plain_array() │ 108 { │ > 109 EIGEN_MAKE_UNALIGNED_ARRAY_ASSERT(15); │ 110 check_static_allocation_size<T,Size>(); │ 111 } Array is using some kind of alignas specifier, asking for 16 byte alignment. Then the assert checks that it is 16 byte aligned. But array (in Valgrind) is 8 byte aligned: (gdb) p &array $8 = (double (*)[16]) 0x45df258 plain_array is wrapped in several classes. I thought that alignment propagated out from aggregate types. If I add this std::cout << "alignof Eigen::Affine3d " << alignof(Eigen::Affine3d) << '\n'; and it says alignof Eigen::Affine3d 16 which is what I expected. When I build with clang++ I see │ 121 operator new (std::size_t sz, std::align_val_t al) So that explains why clang++ is working. I need to look more at what libc is doing. -- You are receiving this mail because: You are watching all bug changes.
