DECL_ALIGN

[Neil Booth]

Richard Henderson wrote:-

> Docs.  __alignof__ is the alignment required for the type,
> not the known alignment of the variable.

OK to commit this patch, then?  It will also allow me to close
PR 3504.

Neil.

	PR c/3504
	* doc/extend.texi: Correct documentation of __alignof__.

Index: extend.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.56
diff -u -p -r1.56 extend.texi
--- extend.texi	2002/01/16 21:00:15	1.56
+++ extend.texi	2002/01/22 23:23:58
@@ -2754,20 +2754,19 @@ Some machines never actually require ali
 data type even at an odd addresses.  For these machines, @code{__alignof__}
 reports the @emph{recommended} alignment of a type.
 
-When the operand of @code{__alignof__} is an lvalue rather than a type, the
-value is the largest alignment that the lvalue is known to have.  It may
-have this alignment as a result of its data type, or because it is part of
-a structure and inherits alignment from that structure.  For example, after
-this declaration:
+When the operand of @code{__alignof__} is an lvalue rather than a
+type, the value is the required alignment for that lvalue.  It may
+have this alignment as a result of its data type, or because it is
+part of a structure and inherits alignment from that structure.  For
+example, after this declaration:
 
 @example
 struct foo @{ int x; char y; @} foo1;
 @end example
 
 @noindent
-the value of @code{__alignof__ (foo1.y)} is probably 2 or 4, the same as
-@code{__alignof__ (int)}, even though the data type of @code{foo1.y}
-does not itself demand any alignment.
+the value of @code{__alignof__ (foo1.y)} is 1, even though its actual
+alignment is probably 2 or 4, the same as @code{__alignof__ (int)}.
 
 It is an error to ask for the alignment of an incomplete type.