[PATCH] Fix ACATS cxa4005 failure at -O

[Daniel Berlin]

On Tue, Apr 15, 2008 at 9:42 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Wed, Apr 9, 2008 at 6:44 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>  > Hi,
>  >
>  >  tree-ssa-structalias.c:do_structure_copy aborts on
>  >
>  >   delete_string ={v} "abcdefghijkl"[1 ...]{lb: 1 sz: 1};
>  >
>  >  which is an ARRAY_RANGE_REF of a STRING_CST because no constraint is returned
>  >  for the RHS and the code expects one:
>  >
>  >   get_constraint_for (lhsop, &lhsc);
>  >   get_constraint_for (rhsop, &rhsc);
>  >   gcc_assert (VEC_length (ce_s, lhsc) == 1);
>  >   gcc_assert (VEC_length (ce_s, rhsc) == 1);
>
>  This is an aggregate array assignment which are not very common and thus
>  likely buggy in the middle-end.  Most of the time we make sure to elide
>  them to memcpy calls during gimplification, but this is of course not
>  always possible.
>
>  From the frontend we get
>
>                 delete_string =
>  VIEW_CONVERT_EXPR<character[1:10]>("abcdefghijkl"[10, 1 ...]{lb: 1 sz:
>  1});
>
>  gimplified to
>
>                 D.1898 = 1;
>                 delete_string = "abcdefghijkl"[D.1898 ...]{lb: 1 sz: 1};
>
>  (similar aggregate comparisons are properly gimplified to memcmp)
>
>
>  >  This stems from get_constraint_for_component_ref:
>  >
>  >   /* String constants are readonly, so there is nothing to really do
>  >      here.  */
>  >   if (TREE_CODE (t) == STRING_CST)
>  >     return;
>
>  As it is obviously bogus to handle the STRING_CST this way (danny
>  introduced this) the patch is IMHO ok, though looking into why we
>  don't gimplify this to a memcpy would be nice as well.
I do not remember why I did this, but it was correct for all languages
at the time (I swear!) :)

Theoretically, the right way to handle strings is to assign each a
unique variable and use that as the constraint.
In reality, they are readonly, so it rarely matters what happens to them.

The patch is fine by me.