Bug 36159 - C++ compiler should issue a warning with missing new operator
Summary: C++ compiler should issue a warning with missing new operator
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Martin Sebor
URL:
Keywords:
: 43874 49585 60202 67911 69250 70441 70603 (view as bug list)
Depends on:
Blocks: 36054 15795
  Show dependency treegraph
 
Reported: 2008-05-06 16:08 UTC by H.J. Lu
Modified: 2016-06-23 16:20 UTC (History)
22 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-10-10 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2008-05-06 16:08:37 UTC
[hjl@gnu-6 tmp]$ cat a.cc
#include <stdio.h>
#include <emmintrin.h>

struct A {
public:
       __m128i m;
       void init() { m = _mm_setzero_si128(); }
};

int main()
{
       A * a = new A;
       printf("Address of A: %p\n", a);
       a->init();
       delete a;
       return 0;
}
[hjl@gnu-6 tmp]$ g++ -m32 -msse3 a.cc
[hjl@gnu-6 tmp]$ ./a.out
Address of A: 0x804a008
Segmentation fault
[hjl@gnu-6 tmp]$

If we add dynamic allocation with explicit alignment support to C++, we immediately have to answer the question: does this extension require new
syntax?

If it doesn't -- in other words, if we just change the way code is generated
for a new-expression -- then some existing carefully-written code will be
broken.

If it does, then existing template code won't take advantage of it. So, for example, if we store our SIMD data in a standard C++ library container, it (probably) won't work because it won't be properly aligned.

This is the reason why no one has yet come up with a general solution to this problem, even though it has been a known issue for over ten years. The best that anyone's been able to do is the class-specific operator new.

For this testcase, g++ should issue an error when the class-specific operator
new is missing.
Comment 1 Andrew Pinski 2008-05-06 16:11:37 UTC
Actually we (Sony) have come up with a solution but not much as come about with it though.

If you read Trevor's proposal, you would have found we did come up with one.
Comment 2 H.J. Lu 2008-05-06 16:28:01 UTC
Trevor, can you scale down your original proposal just to issue an
error when there is no class-specific operator new for a type with
an alignment greater than what malloc() guarantees? It will be
programmer's responsibility to provide appropriate new operator.
Comment 3 Wolfgang Bangerth 2008-05-07 04:21:58 UTC
How is the compiler supposed to know about what alignment malloc can
produce? How can it know that ::operator new doesn't increase the
alignment automatically?

W.
Comment 4 H.J. Lu 2008-05-07 04:56:56 UTC
The default new operator is implemented within gcc. It should be
possible to let g++ know the alignment returned by the new operator.
Comment 5 Andrew Pinski 2008-05-07 05:00:21 UTC
(In reply to comment #4)
> The default new operator is implemented within gcc. It should be
> possible to let g++ know the alignment returned by the new operator.

The default one is but the user can override it as defined by the C++ standard.  Also different OS's return different alignment.  Mac OS X (darwin) returns the 16 byte alignment on both PowerPC and x86.  While x86 Linux returns 8 byte aligned memory.  PPC LV2 returns 16byte aligned memory.  PPC Linux should be returning 16byte aligned memory for the 128bit long double but from what I remember or last heard does not.

-- Pinski
Comment 6 joseph@codesourcery.com 2008-05-07 11:25:06 UTC
Subject: Re:  C++ compiler should issue a warning with  missing
 new operator

On Wed, 7 May 2008, pinskia at gcc dot gnu dot org wrote:

> aligned memory.  PPC LV2 returns 16byte aligned memory.  PPC Linux should be
> returning 16byte aligned memory for the 128bit long double but from what I
> remember or last heard does not.

There is a patch for that glibc bug 
<http://sourceware.org/ml/libc-alpha/2007-11/msg00062.html>, but the glibc 
maintainers have not reviewed it.

Comment 7 H.J. Lu 2009-01-09 01:09:32 UTC
We can solve it with

1. A target should define MALLOC_ABI_ALIGNMENT properly.
2. g++ should issue an error when the default new operator
is used on a type whose alignment is greater than
MALLOC_ABI_ALIGNMENT.
3. It is user's responsibility to provide a new operator to return
a properly aligned memory.
4. g++ can assume memory return by the user-provided new
operator is properly aligned.
Comment 8 H.J. Lu 2010-04-24 02:42:27 UTC
*** Bug 43874 has been marked as a duplicate of this bug. ***
Comment 9 H.J. Lu 2011-06-30 04:50:54 UTC
*** Bug 49585 has been marked as a duplicate of this bug. ***
Comment 10 H.J. Lu 2012-07-15 13:54:21 UTC
*** Bug 53970 has been marked as a duplicate of this bug. ***
Comment 11 Martin Sebor 2015-10-10 16:04:27 UTC
*** Bug 67911 has been marked as a duplicate of this bug. ***
Comment 12 Martin Sebor 2015-10-10 16:07:55 UTC
Confirmed.  As noted in bug 67911, the solution proposed for the next version of C++ is the following:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0035r0.html
Until it's accepted and implemented, issuing a warning would help users avoid the trap.  I happen to be working in this area so I'll see if I can come up with something.
Comment 13 H.J. Lu 2016-01-12 16:53:14 UTC
*** Bug 69250 has been marked as a duplicate of this bug. ***
Comment 14 Martin Sebor 2016-01-31 00:11:06 UTC
*** Bug 60202 has been marked as a duplicate of this bug. ***
Comment 15 Martin Sebor 2016-03-30 03:02:24 UTC
*** Bug 70441 has been marked as a duplicate of this bug. ***
Comment 16 Martin Sebor 2016-04-09 00:16:05 UTC
*** Bug 70603 has been marked as a duplicate of this bug. ***
Comment 17 Marios Hadjieleftheriou 2016-04-09 12:14:43 UTC
(In reply to Martin Sebor from comment #12)
> Confirmed.  As noted in bug 67911, the solution proposed for the next
> version of C++ is the following:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0035r0.html
> Until it's accepted and implemented, issuing a warning would help users
> avoid the trap.  I happen to be working in this area so I'll see if I can
> come up with something.

The link posted above appears to be broken.
Comment 18 Martin Sebor 2016-04-10 20:29:42 UTC
The link works for me.  An older version of the paper is here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3396.htm
If that doesn't work for you either try searching for the paper titled Dynamic memory allocation for over-aligned data by Clark Nelson.
Comment 19 Florian Weimer 2016-06-23 16:20:19 UTC
Current (unreleased) glibc usues this:

# define MALLOC_ALIGNMENT       (2 * SIZE_SZ < __alignof__ (long double) \
				 ? __alignof__ (long double) : 2 * SIZE_SZ)

So the old bug https://sourceware.org/bugzilla/show_bug.cgi?id=6527 is gone.

To my knowledge, this level of alignment is sufficient to cover max_align_t.

These malloc changes are in principle back-portable, but they are a bit on the risky side because where the definition of MALLOC_ALIGNMENT changes, malloc allocation patterns (and eventually RSS usage) are affected.