On Tue, 16 Jun 2015, Eric Botcazou wrote:
> +@item unused
> +@cindex @code{unused} type attribute
> +When attached to a type (including a @code{union} or a @code{struct}),
> +this attribute means that variables of that type are meant to appear
> +possibly unused. GCC does not produce a warning for any variables of
> +that type, even if the variable appears to do nothing. This is often
> +the case with lock or thread classes, which are usually defined and then
> +not referenced, but contain constructors and destructors that have
> +nontrivial bookkeeping functions.
You appear to be duplicating the documentation of an unrelated attribute.
What happens when typeof is applied to a field with reversed storage
order?
> + else if (TYPE_REVERSE_STORAGE_ORDER (t)
> + && TREE_CODE (field) == FIELD_DECL
> + && TREE_CODE (TREE_TYPE (field)) == ARRAY_TYPE)
> + {
> + tree ftype = TREE_TYPE (field);
> + do
> + ftype = TREE_TYPE (ftype);
> + while (TREE_CODE (ftype) == ARRAY_TYPE);
> + if (!RECORD_OR_UNION_TYPE_P (ftype))
> + {
> + tree *ftypep = &TREE_TYPE (field);
> + do {
> + *ftypep = build_distinct_type_copy (*ftypep);
> + TYPE_REVERSE_STORAGE_ORDER (*ftypep) = 1;
> + ftypep = &TREE_TYPE (*ftypep);
> + } while (TREE_CODE (*ftypep) == ARRAY_TYPE);
I don't think this type construction is safe when the array type has
qualified element type. The following invariant is meant to hold: for an
array type whose element type (possibly after going down through several
levels of array types) is qualified, the TYPE_MAIN_VARIANT is a
corresponding array type whose element type is unqualified. So in that
case you need to build two sequences of array types, not one: the main
variants with unqualified element type, and the versions with qualified
element type. See c_build_qualified_type.
--
Joseph S. Myers
jos...@codesourcery.com
