This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: aligned attribute and the new operator (pr/15795) wrote:
> 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
target cutoff).

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
deallocate it.

> 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.

Mark Mitchell
(650) 331-3385 x713

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]