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: Mon, 18 Dec 2006 20:00:04 -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> <4585F26C.firstname.lastname@example.org> <20061218204059.GY7501@playstation.sony.com>
> I can't add much to what has already been discussed in PR/15795 or the
> previous thread on the gcc mailing list.
> You are right, the user has the ability to solve this problem on their
> own. The objective is to make it so they don't have to. Why can't we
> make it just work?
It's a trite answer, but here it is: because all features have an
associated cost, and because C++ is already a very complex feature, and
so the impact of additional features is not easy to see.
Your new functions are not a pure extension; they will change the
meaning of some programs, not just make previously invalid programs
compile. That's the scariest kind of language change, because we have
to convince ourselves that this is OK.
Here's an example of the kind of thing that concerns me:
1. The user has defined operator new() to use a special allocation pool,
with alignment guaranteed to be large enough for their needs.
2. They define a class with a large alignment value (bigger than the
3. As a result, they now end up in __align_new, which then calls
posix_memalign instead of using the pool allocator -- and the program
has silently been broken.
Your extension can change the behavior of a well-written program to do
the wrong thing. As such, I don't think we could even consider it
without a special command-line option -- and, in general, we've avoided
any extension that changes the meaning of a conforming program.
Even if we broke that rule, the existence of the special option means
that this is no longer fully automatic. It also means that users have
to ensure that the points of allocation and points of deallocation are
both compiled with the same setting of the option, or they may end up
calling __align_new to allocate the memory, and plain delete to
> One example of usage on the PS3 is to use a 256-byte aligned class for
> allocating DMA buffers.
If this is really a class, then you can just define operator new for it,
in your library. If it's just an array typedef, with attirbutes, then
you need a wrapper. But, in either case, you can handle this in your
library. As you say, you don't need an extension to handle this.
(650) 331-3385 x713