Re: DATA_ALIGNMENT vs. DECL_USER_ALIGNMENT

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    So, starting from the second (typedef) sample, if I write:

	__typeof__(i) * ptr = &i;
	use (*ptr);

    That should be equivalent to:

	T2 * ptr = &i;
	use (*ptr);

    The code for `use' may assume that the pointer has at least an
    alignment of 2, i.e. the least significant bit of the pointer is zero?

In this case, "use" should know what is being pointed to, so I don't
understand your example at all.

    Robert Dewar, on behalf of Ada, seems to think that the object
    alignment specification implies a _maximum_ alignment as well as a
    minimum.  For fields in structures this is relevant.  But for data
    variables?

This isn't an Ada issue, but a generic one, and I also raised the point.
The issue is one of interfacing.

Consider a type P that is a pointer to type T where I say that type
T has 4-byte alignment.  Now consider a function which is passed an
object of type T.  If that function is not part of the current compilation,
the specifcation of an alignment for T means that the compiler must ensure
that any object of type T must be aligned to *at least* 4 bytes since the
function is entitled to assume that.

Now consider a function that takes an object of type T that is *not* part
of the current compilation.  When generating code to dereference P, it is
not allowed to assume that the alignment of the object pointed to by P
is *more* than four bytes.

This means that it is an error to change the alignment of the *type*
in either direction from what the user specified.

    I have always expected that a user-specific alignment attribute can
    only increase the alignment of a type or object, not decrease it.
    After all, an object with alignment 8 *is* an object with alignment 4,
    for pointer dereferences and arithmetic purposes.

Except in the case above, where you are *importing* an object that type
and need to know what code to generate.  The reference to Ada is just that
these things are discussed specifically in the Ada RM, but they really apply
just as well to GNU C.

    But now I see that decreasing alignment is sometimes useful, because
    that influences how data is packed in memory, which is useful in some
    data structures and things like variables in special sections.

    It seems that in Ada, this "exact alignment" constraint is a language
    requirement.  (Is this correct, Robert?)

Be careful to distinguish the alignment of *type* with the alignment of
an object of that type.  Also be careful to realize that an implementation
must only provide an 'as if' implementation of the standard.

It is certainly true in Ada that if you have
	for x'alignment use 4;
then if you later ask for x'alignment, you must get 4 (bytes).  It's
also true that x'address must be a multiple of 4.  But if the compiler
were actually to tell the linker to align X to 8 bytes, there would be no
way to distinguish that case from the case where it just happened to be
aligned at that boundary.  So doing so would be conforming to the standard.

So the issue with objects is not conformance, but what's "best".  To
me, it seems that if the user goes to the trouble of specifying an
alignment for an object, they are doing so for a reason and it should
not be overriden unless there's a good reason to do that (e.g.,
minimum alignment on a machine, like S390).