Re: [patch] PR32901: handle assignment...(and PR34465 and PR34448)

[Aldy Hernandez <aldyh at redhat dot com>]

> Sure.  If the alternative is uglier, then the patch you posted earlier this 
> week is fine.
>
>> But of course, everyone's going on holiday today, and I'll be eating
>> copious amounts of "lechon asado" over the next week.
>
> Excellent plan.
>
>> Expect a patch sometime next week or early the next.
>
> Thanks!

Hi Diego.  Hi folks.

I have a patch which is mostly done, but I've run into a few snafus
which have me wondering whether all this refactoring is worth the
trouble.

I am calculating all the ancillary data that both
gimplify_init_constructor and the new predicate calculating temporary
creation, will use.  It's being stored in a structure, as suggested,
but there are two problems.

First, we need to calculate the LHS of the initialization ("object" in
gimplify_init_constructor) in order to generate the rest of the info we
need.  To calculate this, we must gimplify the LHS, thus introducing
side-effects while generating the data.

Second, to determine whether we will create a temporary in the second
instance (see below), we need to calculate "size", which has the
side-effect of changing the type of ctor.

            if (size < 0)
              {
                size = int_size_in_bytes (TREE_TYPE (object));
                if (size >= 0)
                  TREE_TYPE (ctor) = type = TREE_TYPE (object);
  SIDE EFFECT HERE^^^^^^^^^^^^^^^^^^^^^
              }

            /* Find the maximum alignment we can assume for the object.  */
            /* ??? Make use of DECL_OFFSET_ALIGN.  */
            if (DECL_P (object))
              align = DECL_ALIGN (object);
            else
              align = TYPE_ALIGN (type);

            if (size > 0 && !can_move_by_pieces (size, align))
  WE NEED SIZE HERE^^^^^^^^^
              {
                tree new = create_tmp_var_raw (type, "C");

Can someone see a clean way of approaching this, or should we just go
back to my original patch?

Aldy