On Fri, Oct 23, 2009 at 2:41 PM, Richard Guenther wrote: > On Fri, Oct 23, 2009 at 2:40 PM, Joseph S. Myers > wrote: >> On Fri, 23 Oct 2009, Richard Guenther wrote: >> >>> On Fri, Oct 23, 2009 at 2:21 PM, Joseph S. Myers >>> wrote: >>> > On Fri, 23 Oct 2009, Richard Guenther wrote: >>> > >>> >> The change is ok, but I wonder why the C FE sets >>> >> TYPE_STRUCTURAL_EQUALITY_P on VLAs.  As you can see >>> > >>> > It's not the front end setting it - tree.c:build_index_type sets it for >>> > the index type with nonconstant bounds, while tree.c:build_array_type sets >>> > it for arrays if it is set for either the element type or the index type. >>> >>> Ah, ok.  I wonder if it is better to handle the trivial cases like this >>> in alias.c and fall back to the structurally canonical type for >>> getting the alias set in case of TYPE_STRUCTURAL_EQUALITY_P >>> then.  Which would be for example type_for_mode () for all >>> integral types, the element type for array types and void * >>> for pointer types. >>> >>> That might be a better approach anyway. >> >> I don't know why alias.c stops where it does for >> TYPE_STRUCTURAL_EQUALITY_P, but reverting the c-common.c change as part of >> changes to make this work in alias.c (that keep the testcase working) is >> preapproved. > > Thanks.  I'll look into this. Thus, I'm playing with the following. It's assuming that structural equality applies recursively, thus if it is set on the array type then the element types also have to be compared structurally. At least I can't see how it could be correct to for S[n] use the alias set of S if the array type has TYPE_STRUCTURAL_EQUALITY_P set. This of course means that this patch will likely uncover the original problem on a different testcase. The patch defines structural equality based on mode equivalence (excluding BLKmode and VOIDmode) and uses component types where the non-structural path does (in addition it also does so for complex types). The patch assumes that TYPE_STRUCTURAL_EQUALITY_P build a self-contained group, so there is no aliasing between a type that has TYPE_STRUCTURAL_EQUALITY_P and a type that has not set TYPE_STRUCTURAL_EQUALITY_P. Otherwise a type with TYPE_STRUCTURAL_EQUALITY_P would implicitly make all structural equivalent types subject to structural comparison - which of course does not work if we compute alias-sets incrementally and on-demand as we do now. Comments? Thanks, Richard.