This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] MALLOC_ABI_ALIGNMENT macro + malloc-alignment param
On Fri, Jul 18, 2008 at 3:17 PM, Olivier Hainque <hainque@adacore.com> wrote:
> Richard Guenther wrote:
>
>> The returned memory only has to be aligned to the maximum alignment
>> of a standard type that fits in the memory.
>
> Humm, that's not my understanding. My understanding is that in
> principle it should accomodate any standard type whatever the input
> size. I think that was Joseph's point earlier in this thread, with a
> link
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_075.html
Ok, I stand corrected on this, but ...
> In practice, while it might be possible that some target allocators
> don't honor the largest alignments, it seems reasonable to count on
> a lower bound greater than one.
... as we detect malloc by means of the malloc attribute and existing
usage includes things such as small-object allocators (which do _not_
need to follow the above, but may return 2-byte or 1-byte aligned
storage), we have to invent a new mechanism to specify alignment
of an allocator function (maybe your patch did that already, I don't
remember). I would suggest a new malloc_align attribute which we
can set to the standard C allocators appropriately with values derived
from the target ABI.
>> On i?86 malloc (8) may return 4-byte aligned storage.
>
>> Instead you have to derive the alignment from the allocation size at
>> each allocation site,
>
> As your malloc(8) example illustrates, we have to cut at some lower
> bound in any case.
>
> How would you compute that ?
The target ABI specifies that.
> I think this is the value we're trying to evaluate, my understanding
> is that it would apply whatever the size, and that, while safe, 1
> would be overly pessimistic.
Well, you might call it overly pessimistic - I call it correct.
>> or which I'm fine with, add a --param to specify minimum alignment
>> which default should be 1 for correctness.
>
> I agree a param would be useful anyhow.
Not anymore with an additional attribute. I think we cannot re-use
the malloc attribute here.
Richard.