This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch/RFC] PR 82085 ("[6/7/8 Regression] ICE: Template variable reference used in nested template alias")
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 30 Oct 2017 10:04:05 -0400
- Subject: Re: [C++ Patch/RFC] PR 82085 ("[6/7/8 Regression] ICE: Template variable reference used in nested template alias")
- Authentication-results: sourceware.org; auth=none
- References: <cf70ae98-a650-d0f9-a1e5-f746f8161f62@oracle.com>
OK.
On Mon, Oct 30, 2017 at 9:52 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Hi,
>
> lately I spent quite a bit of time triaging and resolving ICEs and noticed
> this recently filed regression which, in a wicked way, I find somehow funny.
> In short, we are seeing an ICE in tsubst_copy_and_build, when, for an
> INDIRECT_REF, TREE_TYPE (r) is found null:
>
> case INDIRECT_REF:
> {
> tree r = RECUR (TREE_OPERAND (t, 0));
>
> if (REFERENCE_REF_P (t))
> {
> /* A type conversion to reference type will be enclosed in
> such an indirect ref, but the substitution of the cast
> will have also added such an indirect ref. */
> if (TREE_CODE (TREE_TYPE (r)) == REFERENCE_TYPE)
> r = convert_from_reference (r);
>
> Since Jason's r226642, which fixed a serious issue with multiple Bugzillas,
> we have lookup_template_variable doing:
>
> /* The type of the expression is NULL_TREE since the template-id could
> refer
> to an explicit or partial specialization. */
> tree type = NULL_TREE;
>
> instead of setting type = unknown_type_node and that ultimately leads to the
> ICE for the testcase at issue. Now, I found in a way funny that the body of
> convert_from_reference has:
>
> tree
> convert_from_reference (tree val)
> {
> if (TREE_TYPE (val)
> && TREE_CODE (TREE_TYPE (val)) == REFERENCE_TYPE)
>
> thus, if only somebody had cleaned up with no functionality change the above
> bits of tsubst_copy_and_build to unconditionally call convert_from_reference
> we would not have PR82085. Or at least we would not have it in this form,
> maybe we are only uncovering a much deeper issue?!? Anyway, the trivial
> patchlet below certainly passes testing on x86_64-linux. What do you think?
>
> Thanks, Paolo.
>
> /////////////////////
>