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.
