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

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Jan 3, 2008 10:35 AM, Aldy Hernandez <aldyh@redhat.com> wrote:
> > 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?

I appreciate the efforts to fix all this, but at some point we might consider
reverting the patch that caused this fallout, which is I believe the fix
for PR32901.

Richard.