[PATCH] Introduce __BIGGEST_ALIGNMENT__ macro

[mats petersson]

I don't think the existing binary problem CAN be solved - unless the code
calls some function to enquire about the alignment, and then uses that.
That of course assumes first and foremost that there is a suitable API to
provide this information in the first place.

But having a constant that "if you just recompile, it will be fine" is a
better solution than "you have to change your constant that you invented
for your code to n, then recompile". And it gets more interesting when
architecture A needs alignment of 8, architecture B needs 4, and
architecture C needs alignment of 16. For portable code, this is quite a
lot of work - unless you assume "largest of the different values", but
using 16 can be quite a lot of overhead with many small allocations (linked
lists and trees with small members, for example).

--
Mats



On 13 December 2014 at 19:18, Joerg Sonnenberger <joerg at britannica.bec.de>
wrote:

> On Sat, Dec 13, 2014 at 06:43:03PM +0000, mats petersson wrote:
> > If the alignment, then surely "SuitableAlignment" should also change? It
> > "SuitableAlignment" isn't the right thing to use for "largest alignment",
> > then perhaps a new member is needed, but I thought that
> "SuitableAlignment"
> > was for "The alignment you need to ensure that data is aligned correctly.
>
> But such change doesn't help *existing* binaries. We've had such fun in
> NetBSD with the Unix Domain Socket control message interface before,
> encoding "maximum alignment" implicitly in the ABI is not fun. That's
> why I am asking what the future compatibility promises around this
> interface are.
>
> Joerg
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141213/94cac34c/attachment.html>