Jason Merrill <ja...@redhat.com> writes: > On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely <jwak...@redhat.com> wrote: >> On 08/09/16 09:10 +0200, Marc Glisse wrote: >>> >>> Do we want a generic fallback implementation (similar to >>> gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc / >>> _aligned_free would also be possible. >> >> Making it work for MinGW would be nice. > > OK, this is what I'm checking in; could someone test it on MinGW?
The new tests are failing in various ways on Solaris: * 32-bit: +FAIL: g++.dg/cpp1z/aligned-new1.C (test for excess errors) +WARNING: g++.dg/cpp1z/aligned-new1.C compilation failed to produce executable +FAIL: g++.dg/cpp1z/aligned-new2.C (test for excess errors) +WARNING: g++.dg/cpp1z/aligned-new2.C compilation failed to produce executable +FAIL: g++.dg/cpp1z/aligned-new3.C (test for excess errors) +WARNING: g++.dg/cpp1z/aligned-new3.C compilation failed to produce executable +FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++11 (test for excess errors) +WARNING: g++.dg/cpp1z/aligned-new5.C -std=gnu++11 compilation failed to produc e executable +FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++14 (test for excess errors) +WARNING: g++.dg/cpp1z/aligned-new5.C -std=gnu++14 compilation failed to produc e executable +FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++98 (test for excess errors) +WARNING: g++.dg/cpp1z/aligned-new5.C -std=gnu++98 compilation failed to produc e executable All instances of Excess errors: Undefined first referenced symbol in file operator new(unsigned int, std::align_val_t) /var/tmp//cc_0Nrkd.o ld: fatal: symbol referencing errors libsupc++/new_opa.o contains _ZnwjSt11align_val_t (operator new(unsigned int, std::align_val_t)) while for 64-bit there is _ZnwmSt11align_val_t (operator new(unsigned long, std::align_val_t)) The former isn't matched by config/abi/pre/gnu.ver # C++17 aligned new/delete _ZnwmSt11align_val_t; _ZnwmSt11align_val_tRKSt9nothrow_t; _ZnamSt11align_val_t; _ZnamSt11align_val_tRKSt9nothrow_t; I strongly suspects this needs to be _Znw[jmy]* just as for regular new/delete. * For 64-bit, I get +FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++11 execution test +FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++14 execution test +FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++98 execution test which fails like this: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc gdb shows #7 0xffff80ff1d104bdc in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=0xffff80ff1d2d0c98 <typeinfo for std::bad_alloc>, dest=0xffff80ff1d1028f0 <std::bad_alloc::~bad_alloc()>) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/eh_throw.cc:96 #8 0xffff80ff1d10604c in operator new (sz=4, al=(unknown: 64)) at /vol/gcc/src/hg/trunk/local/libstdc++-v3/libsupc++/new_opa.cc:71 #9 0x00000000004010df in main () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/cpp1z/aligned-new5.C:11 and aligned_alloc(3C) documents The value of alignment must be a valid alignment supported by the sys- tem, that is, any power of two (1, 2, 4, 8, ...), and the value of size must be an integral multiple of alignment. which isn't the case here. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University