This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix ACATS cxa4005 failure at -O
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.