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. Do they? > In any case, constexpr expansion can be more flexible about type coherence > because it is just trying to get a constant value; if that doesn't work out, > we throw it away and fall back on the original expression. We already > handle some cases in cxx_eval_indirect_ref that aren't appropriate for > fold_indirect_ref_1, but this testcase demonstrates that we also want to > adjust the cases that are handled by that function. > > So my options would seem to be either duplicating the whole of > fold_indirect_ref_1, which tempts undesirable divergence, or adding a flag > to that function to enable the more permissive type checking that the > constexpr code wants. > > Does this seem like a reasonable thing to do? So, I'd rather go the above way if it works for this case. Thanks, Richard. >
