This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PR c++/87137] GCC-8 Fix


On Wed, Aug 29, 2018 at 01:36:15PM -0400, Nathan Sidwell wrote:
> --- gcc/cp/class.c	(revision 263959)
> +++ gcc/cp/class.c	(working copy)
> @@ -4041,6 +4041,32 @@ layout_nonempty_base_or_field (record_la
>        field_p = true;
>      }
>  
> +  /* PR c++/87137 When ms_bitfield_layout_p is in effect, place_field
> +     used to just look at the DECL's TREE_CHAIN to see if it ended the
> +     struct.  That was ok when only FIELD_DECLs and TYPE_DECLs were on
> +     the chain, AND the TYPE_DECLs were known to be last.  That
> +     stopped working when other things, such as static members were
> +     also placed there.  However, in GCC 8 onwards all members are on
> +     the chain (adding member functions).  We want to restore the
> +     pre-GCC-8 behaviour, so the ABI doesn't change in a point
> +     release.  Because the middle-end doesn't know about
> +     TEMPLATE_DECL, we have to do nastiness here, to make DECL_CHAIN
> +     look like it used to before calling place_field.  THIS IS STILL
> +     WRONG, but it's the same wrongness ass gcc-7 and earier.  */

s/ass gcc-7 and earier/as gcc-7 and earlier/ ?

> +  tree chain = NULL_TREE;
> +  if (targetm.ms_bitfield_layout_p (rli->t))
> +    {
> +      tree probe = decl;
> +      while ((probe = TREE_CHAIN (probe)))

Any reason you are using TREE_CHAIN rather than DECL_CHAIN everywhere (in
comments as well as here and below?
Shouldn't all chain elts be decls?

> +	if (TREE_CODE (STRIP_TEMPLATE (probe)) != FUNCTION_DECL)
> +	  break;
> +      if (probe != TREE_CHAIN (decl))
> +	{
> +	  chain = TREE_CHAIN (decl);
> +	  TREE_CHAIN (decl) = probe;
> +	}
> +    }
> +
>    /* Try to place the field.  It may take more than one try if we have
>       a hard time placing the field without putting two objects of the
>       same type at the same address.  */
> @@ -4111,6 +4137,11 @@ layout_nonempty_base_or_field (record_la
>  	break;
>      }
>  
> +  if (chain)
> +    /* Restore the original chain our ms-bifield-offset shenanigans
> +       above overwrote.  */
> +    TREE_CHAIN (decl) = chain;
> +  
>    /* Now that we know where it will be placed, update its
>       BINFO_OFFSET.  */
>    if (binfo && CLASS_TYPE_P (BINFO_TYPE (binfo)))

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]