RFA (libstdc++): PATCH to implement C++17 over-aligned new

[Rainer Orth]

Jason Merrill <jason@redhat.com> writes:

> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely <jwakely@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