Re: [patch 2/6] scalar-storage-order merge: C front-end

[Joseph Myers <joseph at codesourcery dot com>]

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
joseph@codesourcery.com