This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Richard Guenther <rguenther at suse dot de>, gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 7 Jun 2011 12:19:59 +0200
- Subject: Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))
- References: <4DEDB98F.6010508@redhat.com>
On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill <jason@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.
>