Re: [patch]: new returns misaligned pointers

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:

    >> Makes sense.  Could you mention for which ports this makes a
    >> difference?  If it does make a difference with an existing
    >> port...

    Richard> Of the 16, 11 have BIGGEST_ALIGNMENT smaller than
    Richard> `double', and 4 have BIGGEST_ALIGNMENT larger, for a
    Richard> 128-bit `long double'.  SH has special problems due to
    Richard> -malign-double affecting things.

    Richard> I hadn't realized there were quite so many victims of
    Richard> change.

Interesting.  So, what we have here is a case where the current
compiler is clearly broken (it may sometimes produce insufficiently
aligned memory), but fixing it this way does indeed seem to break the
ABI, as I had feared.

My suggestion, in such cases, is to break the ABI only for the
programs that are already broken because they are misaligned.  So, we
should see if we can make the cookie be the same size for types that
were already sufficiently aligned, but bigger for types that were not.
This will take more work than the current patch, of course.  I think
we should revert that change, and let Diego provide a more complete
fix.

Of course, for the new ABI, we can do anything we want.  Except that
now it looks likely the new ABI will be the IA64 C++ ABI, so we'll
have to do whatever is mandated there. :-)

    Richard> Might I suggest, if we're going to decide to break
    Richard> things, that instead of changing to always using
    Richard> BIGGEST_ALIGNMENT, that we use the alignment of the type
    Richard> being allocated?  Seems like that way we'd avoid wasting
    Richard> little bits of memory unnecessarily.

I agree.  I'm not quite sure why Diego thinks we should necessarily
use whatever malloc returns; malloc could well return something with
an even greater alignment that BIGGEST_ALGINMENT.  As long as things
are appropriately aligned for the things in the array, we're OK.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com