This is the mail archive of the gcc@gcc.gnu.org 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)


* Ian Lance Taylor <iant@google.com> [2006-10-10 10:15]:
> trevor_smigiel@playstation.sony.com writes:
> 
> >   - the default versions of operator new and the aligned version of
> >     operator new should be defined in the same section.  That way,
> >     when a user overrides the default operator new, they will get
> >     a link error (duplicate definitions of new) unless they also
> >     define the aligned version of operator new.
> 
> That would be a bad idea since it would break standard conformant
> programs which only override the default operator new.

Ahh, right.  Regardless, I've realized this technique won't work anyway.
No error would be given when the implementation of operator new is
declared weak, which is common enough.

There are some other possibilities, none of them perfect, like a command
line option, or teaching the linker something about operator new.  

> You are implicitly assuming that we know the alignment of memory
> returned by new.  If we know that, then whenever we need aligned
> memory, we can ask for a bit more memory and force the alignment.
> That will always work and avoids the concerns of overriding new.  We
> can generate more optimal code by providing a command line option
> which specifies the alignment of memory returned by new.

I think I'm assuming the same thing GCC already assumes about new.  I
don't see any thing in GCC that attempts to align the result of a call
to operator new.  For some targets it doesn't matter, for example, when
load and store instructions work on unaligned addresses, but pr/15795
points out a case where this doesn't work.  

Forcing the alignment of the result of new isn't going to work because
we have no way to reconstruct the correct address when calling delete.
We could save the correct address at the beginning of the memory
returned, but that is an ABI change.  

If we are willing to consider an ABI change, I think an approach that
allows new to call some form of memalign would be better than having the
compiler force alignment after calling new.  

Are we open to making an ABI change?

For now, I will still promote the original idea of having a second
version of new with an alignment argument.  And require a command line
option to emit calls to the aligned version of the default new operator.
Is a command line option sufficient?

Trevor


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