On Tue, 7 Jun 2011, Richard Guenther wrote: > On Tue, Jun 7, 2011 at 12:27 PM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Jun 07, 2011 at 12:19:59PM +0200, Richard Guenther wrote: > >> On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill <ja...@redhat.com> wrote: > >> > In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an > >> > ARRAY_REF > >> > because T != unsigned. Even if it were just a typedef to unsigned, that > >> > isn't close enough, but in this case it's a typedef to const unsigned. > >> > > >> > I'm not sure what the type coherence rules are for ARRAY_REF. Is it > >> > really > >> > necessary that the type of the ARRAY_REF match exactly the element type > >> > of > >> > the array? > >> > >> I _think_ that you can unconditionally change the code to do > >> > >> TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2) > >> && TYPE_QUALS (t1) == TYPE_QUALS (t2) > >> > >> now, I'm not sure if for the testcase T and unsigned differ in qualifiers. > > > > I guess folding into array_ref that way is fine, but you should in the end > > fold_convert_loc it to the expected type, while the middle-end has the > > notion of useless type conversions, fold-const.c is also used by FEs and > > I think it is expected to have the types exactly matching. > > So (T)s1[10] instead of s1[10] in this case. > > I'm not sure that's a good idea if the caller wants an lvalue.
Rather build the array-ref with type T directly (thus, with a mismatch between the type of the array-ref and the element type). Richard.
