3183 – Spec of align attribute needs work

There are ambiguities and inconsistencies in how the align attribute is described in the D specification. What follows is a cut-down version of the unanswered post at the given URL, with a few bits thrown in from other posts.
1. Is the whole purpose of it for portability of data or for C ABI compatibility?
ctod.html:
"Clearly, since much of the point to setting alignment is for 
portability of data, a portable means of expressing it is necessary."
attribute.html:
"AlignAttribute is meant for C ABI compatiblity [sic], which is not the 
same thing as binary compatibility across diverse platforms. For that, 
use packed structs:"
2. attribute.html describes align as matching the behaviour of the companion C compiler. What if there's no companion C compiler, or the companion C compiler doesn't support alignment control at the level it has been used in the D code?
3. I had for ages made out align to be purely about the relative alignment of members within a struct. But a discussion at
http://tinyurl.com/nqs2n3#N87948
(that message onwards) got me confused until I realised that people were interpreting it as absolute alignment. The spec doesn't clarify one way or the other. Which is it meant to be?
4. Following on from point 3, should it apply only to structs as is currently documented? Or should it work on unions as well? Even arbitrary variable declarations?
5. And how should the compiler handle it if used where inapplicable? There are the odd bits in the spec on this, but it wants rethinking. This is just one case of issue 3118.

1. C ABI compatibility.
2. There's always a companion C compiler, as D relies on the existence of the C runtime library.
3. It's the way the companion C compiler aligns.
4. Unions members are all at offset 0. Unions are aligned according to the alignment of their largest field.
5. It is ignored for non-struct fields.

(In reply to comment #1)
> 2. There's always a companion C compiler, as D relies on the existence of the C
> runtime library.
So a prerequisite for writing a D compiler from scratch is to write a C compiler first? Still, that doesn't answer my question beyond the first 7 words.
> 3. It's the way the companion C compiler aligns.
Still, that this may be absolute or relative depending on the companion C compiler ought to be mentioned in the D spec at least to crack down on the user confusion of which I have been a victim.
> 4. Unions members are all at offset 0. Unions are aligned according to the
> alignment of their largest field.
You mean aligned in a containing struct, or aligned absolutely _if_ the implementation interprets alignment as absolute? Neither seems to be happening in my test (1.046):
----------
align(1) struct Qwert {
 byte b1;
 align(1) struct {
 byte b2;
 union {
 align (4) struct { int i; }
 }
 }
}
pragma(msg, "Qwert.alignof == " ~ Qwert.alignof.stringof);
pragma(msg, "Qwert.b1.alignof == " ~ Qwert.b1.alignof.stringof);
pragma(msg, "Qwert.b2.alignof == " ~ Qwert.b2.alignof.stringof);
pragma(msg, "Qwert.i.alignof == " ~ Qwert.i.alignof.stringof);
pragma(msg, "Qwert.b1.offsetof == " ~ Qwert.b1.offsetof.stringof);
pragma(msg, "Qwert.b2.offsetof == " ~ Qwert.b2.offsetof.stringof);
pragma(msg, "Qwert.i.offsetof == " ~ Qwert.i.offsetof.stringof);
----------
Qwert.alignof == 1u
Qwert.b1.alignof == 1u
Qwert.b2.alignof == 1u
Qwert.i.alignof == 4u
Qwert.b1.offsetof == 0u
Qwert.b2.offsetof == 1u
Qwert.i.offsetof == 2u
----------
But to both 4 and 5, I said "should", i.e. I was pondering over what's desirable and whether the spec ought to be changed, not what the current spec or behaviour is.

Fixed dmd 1.047 and 2.032