public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Andrew Pinski <pinskia@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r12-1150] Use is_empty_type instead of zero-sized type.
Date: Tue,  1 Jun 2021 18:29:29 +0000 (GMT)	[thread overview]
Message-ID: <20210601182929.72C5C3839C5B@sourceware.org> (raw)

https://gcc.gnu.org/g:34aae6b561871d6d8b10c810f303cb6f18b5fdd0

commit r12-1150-g34aae6b561871d6d8b10c810f303cb6f18b5fdd0
Author: Andrew Pinski <apinski@marvell.com>
Date:   Mon May 31 12:25:28 2021 +0000

    Use is_empty_type instead of zero-sized type.
    
    Instead of only removing assignments of zero-sized types,
    assignments of all empty types should be removed during gimplification.
    This moves to use is_empty_type which will be used in other places too.
    
    OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
    
    Thanks,
    Andrew Pinski
    
    gcc/ChangeLog:
    
            * gimplify.c (zero_sized_field_decl): Delete
            (zero_sized_type): Delete
            (gimplify_init_ctor_eval): Use is_empty_type instead
            of zero_sized_field_decl.
            (gimplify_modify_expr): Use is_empty_type instead of
            zero_sized_type.

Diff:
---
 gcc/gimplify.c | 34 +++++++---------------------------
 1 file changed, 7 insertions(+), 27 deletions(-)

diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 3ca29cedad8..39f5b973d18 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -4644,28 +4644,6 @@ gimplify_init_ctor_eval_range (tree object, tree lower, tree upper,
   gimplify_seq_add_stmt (pre_p, gimple_build_label (loop_exit_label));
 }
 
-/* Return true if FDECL is accessing a field that is zero sized.  */
-
-static bool
-zero_sized_field_decl (const_tree fdecl)
-{
-  if (TREE_CODE (fdecl) == FIELD_DECL && DECL_SIZE (fdecl)
-      && integer_zerop (DECL_SIZE (fdecl)))
-    return true;
-  return false;
-}
-
-/* Return true if TYPE is zero sized.  */
-
-static bool
-zero_sized_type (const_tree type)
-{
-  if (AGGREGATE_TYPE_P (type) && TYPE_SIZE (type)
-      && integer_zerop (TYPE_SIZE (type)))
-    return true;
-  return false;
-}
-
 /* A subroutine of gimplify_init_constructor.  Generate individual
    MODIFY_EXPRs for a CONSTRUCTOR.  OBJECT is the LHS against which the
    assignments should happen.  ELTS is the CONSTRUCTOR_ELTS of the
@@ -4699,11 +4677,13 @@ gimplify_init_ctor_eval (tree object, vec<constructor_elt, va_gc> *elts,
       gcc_assert (purpose);
 
       /* Skip zero-sized fields, unless value has side-effects.  This can
-	 happen with calls to functions returning a zero-sized type, which
+	 happen with calls to functions returning a empty type, which
 	 we shouldn't discard.  As a number of downstream passes don't
-	 expect sets of zero-sized fields, we rely on the gimplification of
+	 expect sets of empty type fields, we rely on the gimplification of
 	 the MODIFY_EXPR we make below to drop the assignment statement.  */
-      if (! TREE_SIDE_EFFECTS (value) && zero_sized_field_decl (purpose))
+      if (!TREE_SIDE_EFFECTS (value)
+	  && TREE_CODE (purpose) == FIELD_DECL
+	  && is_empty_type (TREE_TYPE (purpose)))
 	continue;
 
       /* If we have a RANGE_EXPR, we have to build a loop to assign the
@@ -5781,11 +5761,11 @@ gimplify_modify_expr (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p,
   if (ret != GS_UNHANDLED)
     return ret;
 
-  /* For zero sized types only gimplify the left hand side and right hand
+  /* For empty types only gimplify the left hand side and right hand
      side as statements and throw away the assignment.  Do this after
      gimplify_modify_expr_rhs so we handle TARGET_EXPRs of addressable
      types properly.  */
-  if (zero_sized_type (TREE_TYPE (*from_p))
+  if (is_empty_type (TREE_TYPE (*from_p))
       && !want_value
       /* Don't do this for calls that return addressable types, expand_call
 	 relies on those having a lhs.  */


                 reply	other threads:[~2021-06-01 18:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210601182929.72C5C3839C5B@sourceware.org \
    --to=pinskia@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).