[Bug c++/59898] New: alignment problems in std::map with avx/avx2

[Bug c++/59898] New: alignment problems in std::map with avx/avx2

[ignat at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898

            Bug ID: 59898
           Summary: alignment problems in std::map with avx/avx2
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ignat at gmx dot net

Created attachment 31904
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31904&action=edit
avx_bug.cc

The following code segfaults when compiled with -mavx or -mavx2 on g++ (Debian
4.7.2-5) 4.7.2 on Linux x86_64 (Xeon(R) CPU E3-1240 v3). This also applies to
unordered_map and can also happen when assigning to iterators when it->second
is a 32-byte vector type. 

#include <map>

typedef int vec256_t __attribute__ ((__vector_size__ (32)));
std::map<int,vec256_t> m;

int main() {
  vec256_t v;
  m[0]=v;
  return 0;
}

reproduce with:

$ g++ avx_bug.cc -o avx_bug -mavx2 && ./avx_bug
Segmentation fault

thx

ignatius

[Bug c++/59898] alignment problems in std::map with avx/avx2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
User error.  The standard allocators don't guarantee sufficient alignment for
the vector types.

[Bug c++/59898] alignment problems in std::map with avx/avx2

[ignat at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898

--- Comment #2 from ignat at gmx dot net ---
(In reply to Jakub Jelinek from comment #1)
> User error.  The standard allocators don't guarantee sufficient alignment
> for the vector types.

OMG, I see. Thx for clarifying. So this means that C++ is incapable of keeping
track of the alignment requirements for its types for dynamic allocation and I
so far merely got lucky with SSE as malloc happens to return 16-byte aligned
pointers on 64-bit Linux. :-(

Now that I know what to look for, I see ad-hoc fixes for this design flaw, ehm,
"feature" all over the place. Oh well, yet another stupid incantation to get
things to work ...

thx

ignatius

[Bug c++/59898] alignment problems in std::map with avx/avx2

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This unfortunately needs to be changed in the C++ standard, as long as the
operator new functions/methods that must be used and user can override with
their versions don't take the alignment as some parameter, there is no way to
find the alignment info and call say posix_memalign or memalign instead of
malloc under the hood.  And, increasing the guaranteed alignment of malloc or
even just operator new unconditionally to the highest possible alignment of any
vector (right now 64-bytes for Skylake) would waste lots of memory for the
common case of programs that don't really need it.

[Bug c++/59898] alignment problems in std::map with avx/avx2

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
Here is a link to what the future (C++17) might look like for alignment:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm

[Bug c++/59898] alignment problems in std::map with avx/avx2

[ignat at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59898

--- Comment #5 from ignat at gmx dot net ---
16 overloadable memory allocation functions??? brave new world!

Nothing against the possibility to have explicit alignment (when you need to
align to a cache line, page or disk-block), but why not just do the right thing
and let new return properly aligned pointers by default as it's supposed to do?
Isn't that the idea of using a typed language in the first place?

Unless I have missed something, I thought the whole point of introducing the
alignof operator is exactly to make this possible for user defined allocators.
And of course nothing has ever prevented the builtin new to return properly
aligned pointers as the compiler internally always has this info. Just because
a standard allows to return misaligned pointers to users doesn't mean the
implementation has to.

ignatius