This is the mail archive of the
mailing list for the GCC project.
Re: aligned attribute and the new operator (pr/15795)
- From: Mark Mitchell <mark at codesourcery dot com>
- To: trevor_smigiel at playstation dot sony dot com
- Cc: gcc-patches at gcc dot gnu dot org, Ian Lance Taylor <iant at google dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>, Russell_Olsen at playstation dot sony dot com
- Date: Sun, 17 Dec 2006 17:44:12 -0800
- Subject: Re: aligned attribute and the new operator (pr/15795)
- References: <20061010010443.GM24220@playstation.sony.com> <firstname.lastname@example.org> <20061012030808.GA5076@playstation.sony.com> <452E8371.email@example.com> <20061216024943.GW7501@playstation.sony.com>
> I've attached a preliminary patch for the sake of discussion and to
> see if this approach is ok.
> Briefly, the idea is to introduce four new special functions,
> void* __align_new (std::size_t size, std::size_t align);
> void* __align_new_a (std::size_t size, std::size_t align);
> void __align_delete (void* ptr, std::size_t align);
> void __align_delete_a (void* ptr, std::size_t align);
> When a type being operated on with new or delete has alignment greater
> than some target defined value the front end searches for one of the
> special functions and replaces the call.
I don't understand the motivation for this patch.
First, from C99 7.20.3, malloc is required to return storage that is
aligned sufficiently for any type that fits in the size requested:
The pointer returned if the allocation succeeds is suitably aligned so
that it may be assigned to a pointer to any type of object and then used
to access such an object or an array of such objects in the space
allocated (until the space is explicitly deallocated).
So, you're apparently stuck with a non-conforming implementation of
malloc? Why can't it just be fixed?
Second, you could replace the default "operator new" and "operator
delete" to call a more-aligned malloc, e.g., posix_memalign.
The only thing I can think of is that you have small type with very
strong alignment requirements (e.g., an 8-byte type with a 256-byte
alignment requirements) and so you want to be able to allocate most 8
byte types without this alignment requirement? Is that the situation?
Since we're in a C++ context, I would think the right solution is to
create a class wrapper for the type with its own class-specific new and
(650) 331-3385 x713