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

[Jeff Law <law at redhat dot com>]

On 10/06/2015 05:02 AM, Eric Botcazou wrote:
> This is the C front-end + C family part.
>
> 	* doc/extend.texi (type attributes): Document scalar_storage_order.
> 	(Structure-Packing Pragmas): Rename into...
> 	(Structure-Layout Pragmas): ...this.  Document scalar_storage_order.
> 	* doc/invoke.texi (C Dialect Options): Document -fsso-struct
> 	(Warnings): Document -Wno-scalar-storage-order.
> 	* flag-types.h (enum scalar_storage_order_kind): New enumeration.
> c-family/
> 	* c-common.c (c_common_attributes): Add scalar_storage_order.
> 	(handle_scalar_storage_order_attribute): New function.
> 	* c-pragma.c (global_sso): New variable.
> 	(maybe_apply_pragma_scalar_storage_order): New function.
> 	(handle_pragma_scalar_storage_order): Likewise.
> 	(init_pragma): Register scalar_storage_order.
> 	* c-pragma.h (maybe_apply_pragma_scalar_storage_order): Declare.
> 	* c.opt (Wscalar-storage-order): New warning.
> 	(fsso-struct=): New option.
> c/
> 	* c-decl.c (finish_struct): If the structure has reverse storage
> 	order, rewrite the type of array fields with scalar component.  Call
> 	maybe_apply_pragma_scalar_storage_order on entry.
> 	* c-typeck.c (build_unary_op) <ADDR_EXPR>: Remove left-overs.  Issue
> 	errors on bit-fields and reverse SSO here and not...
> 	(c_mark_addressable): ...here.
> 	(output_init_element): Adjust call to initializer_constant_valid_p.
> 	(c_build_qualified_type): Propagate TYPE_REVERSE_STORAGE_ORDER.
>
>   doc/extend.texi     |   69 ++++++++++++++++++++++++++++++++++++++++++--------
>   doc/invoke.texi     |   22 +++++++++++++++-
>   flag-types.h        |    9 +++++-
>   c-family/c.opt      |   17 ++++++++++++
>   c-family/c-common.c |   47 ++++++++++++++++++++++++++++++++++-
>   c-family/c-pragma.c |   50 +++++++++++++++++++++++++++++++++++++
>   c-family/c-pragma.h |    1
>   c/c-typeck.c        |   66 ++++++++++++++++++++++++++++++++++---------------
>   c/c-decl.c          |   48 +++++++++++++++++++++++++-----------
>   8 files changed, 273 insertions(+), 47 deletions(-)
>
> -- Eric Botcazou
>
>
> sso-c.diff
>
>
> Index: doc/extend.texi
> ===================================================================
> --- doc/extend.texi	(.../trunk/gcc)	(revision 228112)
> +++ doc/extend.texi	(.../branches/scalar-storage-order/gcc)	(revision 228133)
> @@ -6310,6 +6310,42 @@ of the structure or union is placed to m
> +@itemize
> +@item Taking the address of a scalar field of a @code{union} or a
> +@code{struct} with reverse scalar storage order is not permitted and will
> +yield an error
Seems reasonable.  Certainly avoids a host of problems tracking this 
stuff later I bet.


> +static tree
> +handle_scalar_storage_order_attribute (tree *node, tree name, tree args,
> +				       int flags, bool *no_add_attrs)
> +{
> +  tree id = TREE_VALUE (args);
> +  tree type;
> +
> +  if (TREE_CODE (*node) == TYPE_DECL
> +      && ! (flags & ATTR_FLAG_CXX11))
> +    node = &TREE_TYPE (*node);
> +  type = *node;
> +
> +  if (BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN)
> +    error ("scalar_storage_order is not supported");
You might want to consider indicating why it's not supported.  Not that 
I expect folks to be using this on a pdp11 :-)



> Index: c/c-typeck.c
> ===================================================================
> --- c/c-typeck.c	(.../trunk/gcc)	(revision 228112)
> +++ c/c-typeck.c	(.../branches/scalar-storage-order/gcc)	(revision 228133)
> @@ -4173,18 +4173,10 @@ build_unary_op (location_t location,
>   	  goto return_build_unary_op;
>   	}
>
> -      /* For &x[y], return x+y */
> -      if (TREE_CODE (arg) == ARRAY_REF)
> -	{
> -	  tree op0 = TREE_OPERAND (arg, 0);
> -	  if (!c_mark_addressable (op0))
> -	    return error_mark_node;
> -	}
Do we still get a proper diagnostic for &x[y] where x isn't something we 
can mark addressable?

Our testsuites aren't particularly good (IMHO) at ensuring we're getting 
diags in all the cases where they're required.

No real objections, assuming that &x[y] diagnostics is still handled 
correctly somewhere.