Aligned Allocator snippet not compiling on gcc/5.4.0

[Maximilian Bremer]

Hi Klaus,

I'm having some issues compiling a vector with the blaze::AlignedAllocator when the type T in std::vector<T,blaze::AlignedAllocator<T>> is not copy assignable.

This only happens on gcc/5.2 gcc/5.4.0, I get the minimal working example to compile on gcc/6.1, gcc/7.1.0, gcc/7.2.0.

Would you be willing to fix this? I know you don't test on gcc/5 anymore.

Thanks,

Max

Details:

g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

Blaze commit: f0755dea0e03f9739e45d084d5473b980708e166

Compiler flags: -std=c++14

[Klaus Iglberger]

Hi Maximilan!

Thanks for pointing out this potential Blaze defect. We can reproduce the compilation issue even with gcc/5.5. However, the error messages suggest that the problem is not related to memory allocation or the implementation of AlignedAllocator, but is directly related to the implementation of std::vector and the STL algorithms in gcc/5.5:

...
/opt/local/include/gcc5/c++/bits/stl_algobase.h:359:18: error: use of deleted function 'A& A::operator=(A&&)'
        *__result = std::move(*__first);
...

Apparently gcc/5.x treats custom allocators and std::allocator differently, which causes this problem. The problem has apparently been fixed in the gcc/6.x releases. We have tested this hypothesis with a primitive allocator implementation:

template< typename T >
struct TestAllocator
{
   using value_type = T;

   inline T* allocate( size_t numObjects, const void* /*localityHint*/ = nullptr )
   {
      return reinterpret_cast<T*>( new char[numObjects*sizeof(T)] );
   }

   inline void deallocate( T* ptr, size_t /*numObjects*/ ) noexcept
   {
      delete[] reinterpret_cast<char*>( ptr );
   }
};

template< typename T1, typename T2 >
inline bool operator==( const TestAllocator<T1>&, const TestAllocator<T2>& ) noexcept
{
   return true;
}

template< typename T1, typename T2 >
inline bool operator!=( const TestAllocator<T1>&, const TestAllocator<T2>& ) noexcept
{
   return false;
}

int main()
{
   using VT = std::vector<A,TestAllocator<A>>;
   VT v;
   v = VT();
}

Even for this primitive allocator we experience the same compilation error. From our point this proves that the problem is gcc related and not Blaze related. Thus unfortunately we cannot resolve this issue. Still, thanks a lot for pointing out this problem,

Best regards,

Klaus!

[Maximilian Bremer]

I totally understand.

Thanks for looking at it!

Max

[Terry Tucker]

As someone who has worked with data annotation, I found this article on raising the ethical bar and addressing bias in data annotation to be incredibly insightful. The author does an excellent job of explaining what bias is and how it can impact the accuracy and fairness of data annotation. One of the most important points made in the article is that bias can be unintentional. As someone who has annotated data, I can attest to the fact that it can be easy to fall into patterns or assumptions without even realizing it. This is why it's so important to have a diverse team of annotators who can bring different perspectives and experiences to the table. The article also highlights the importance of transparency in the annotation process. It's crucial that annotators understand the purpose of the data they are working with and how it will be used. This can help to prevent unintentional bias and ensure that the data is being annotated in a way that is fair and accurate. I highly recommend giving it https://www.techmaish.com/raising-the-ethical-bar-what-is-bias-in-data-annotation/ a read. Overall, I found this article to be a valuable resource for anyone working with data annotation. It's a reminder that we all have a responsibility to be aware of our biases and work to address them in order to create more ethical and accurate data sets.