[MinGW-Notify] [mingw] #40315: c++17 std::aligned_alloc

Back to archive index
MinGW Notification List mingw****@lists*****
Mon Apr 13 20:03:23 JST 2020

#40315: c++17 std::aligned_alloc

  Open Date: 2020-04-10 05:55
Last Update: 2020-04-13 12:03

URL for this Ticket:
RSS feed for this Ticket:


Last Changes/Comment on this Ticket:
2020-04-13 12:03 Updated by: keith


FWIW, as a trivial example, the following foo.cc works:

 1.  #include <cstdio>
 2.  #include <cstdlib>
 4.  #if __cplusplus >= 201703L && defined __MINGW32__
 5.  #include <malloc.h>
 7.  #undef  free
 8.  #define free  aligned_free
10.  extern "C"
11.  { static inline __attribute__((__always_inline__))
12.    void *aligned_alloc( size_t align, size_t wanted )
13.    { return __mingw_aligned_offset_malloc( wanted, align, (size_t)(0) ); }
15.    static inline __attribute__((__always_inline__))
16.    void aligned_free( void *ptr ){ return __mingw_free( ptr ); }
17.  }
19.  namespace std
20.  { using ::aligned_alloc;
21.    using ::aligned_free;
22.  }
23.  #endif  // C++17 && __MINGW32__
25.  int main()
26.  { int* p1 = static_cast<int*>(std::malloc(10*sizeof *p1));
27.    std::printf("default-aligned address:   %p\n", static_cast<void*>(p1));
28.    std::free(p1);
30.    int* p2 = static_cast<int*>(std::aligned_alloc(1024, 1024));
31.    std::printf("1024-byte aligned address: %p\n", static_cast<void*>(p2));
32.    std::free(p2);
33.  }

When cross-compiled, on my GNU/Linux host, and subsequently run under wine,
this produces output similar to:

$ mingw32-g++ -std=gnu++17 foo.cc
$ ./a.exe
default-aligned address:   00230F70
1024-byte aligned address: 00231400

Unfortunately, for more general application, the above is intrinsically unsafe.
The problem is that, while __mingw_aligned_offset_malloc(), (in terms of which
aligned_alloc() is implemented), returns a pointer to heap memory, that pointer
is incompatible with Microsoft's realloc() and free() functions; thus, if that
pointer were to be passed to any (third party) function, which might then pass
it to realloc(), or to free(), the behaviour would be undefined. (Of course,
the same criticism could be levelled at Microsoft's own over-aligned heap
allocation functions, each of which also returns a pointer to heap memory, and
which in turn, is equally incompatible with their realloc() and free()

Ticket Status:

      Reporter: drakbar
         Owner: (None)
          Type: Issues
        Status: Open
      Priority: 5 - Medium
     MileStone: (None)
     Component: GCC
      Severity: 5 - Medium
    Resolution: None

Ticket details:

According to cppreference, the function std::aligned_alloc is apart of C++17.
When trying to compile the example code found at that page, the following
compilation error occurs:

src code

 1.  #include <cstdio>
 2.  #include <cstdlib>
 4.  int main()
 5.  {
 6.      int* p1 = static_cast<int*>(std::malloc(10*sizeof *p1));
 7.      std::printf("default-aligned address:   %p\n", static_cast<void*>(p1));
 8.      std::free(p1);
10.      int* p2 = static_cast<int*>(std::aligned_alloc(1024, 1024));
11.      std::printf("1024-byte aligned address: %p\n", static_cast<void*>(p2));
12.      std::free(p2);
13.  }

compilation output

$g++ -std=c++17 alignment.cpp -o main
alignment.cpp: In function 'int main()':
alignment.cpp:10:38: error: 'aligned_alloc' is not a member of 'std'
 10 |     int* p2 = static_cast<int*>(std::aligned_alloc(1024, 1024));

gcc version

Target: x86_64-w64-mingw32
Configured with: ../gcc-9.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --enable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 9.3.0 (Rev1, Built by MSYS2 project)


Windows 10 Build: 18362.720

linker version

GNU ld (GNU Binutils) 2.34

mingw version

not quite sure which number is the relevant one in _mingw.h


build environment

I have tested using both windows command prompt and the msys-w64 shell, and
both yield the same result

MINGW64_NT-10.0-18362  3.0.7-338.x86_64 2019-07-11 10:58 UTC x86_64 Msys

Ticket information of MinGW - Minimalist GNU for Windows project
MinGW - Minimalist GNU for Windows Project is hosted on OSDN

Project URL: https://osdn.net/projects/mingw/
OSDN: https://osdn.net

URL for this Ticket:
RSS feed for this Ticket:

More information about the MinGW-Notify mailing list
Back to archive index