This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PING^2] [PR46003, C++] Fix the assertion failure in build_target_expr
- From: "Yufeng Zhang" <Yufeng dot Zhang at arm dot com>
- To: "'Jason Merrill'" <jason at redhat dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, "'Mark Mitchell'" <mark at codesourcery dot com>
- Date: Mon, 7 Mar 2011 18:27:50 -0000
- Subject: RE: [PING^2] [PR46003, C++] Fix the assertion failure in build_target_expr
- References: <000401cbd209$c85e6840$591b38c0$@Zhang@arm.com> <4D645152.4060902@redhat.com> <000501cbd506$c4a09750$4de1c5f0$@Zhang@arm.com> <4D693A7B.7080103@redhat.com> <000001cbd902$c51c4f80$4f54ee80$@Zhang@arm.com> <4D702684.9070503@redhat.com>
> On 03/03/2011 11:39 PM, Jason Merrill wrote:
> I think rather that the problem is in build_conditional_expr; it
> should have a template case that just determines the appropriate
> type and then builds up a COND_EXPR with that type from the
> unconverted operands, like we do for calls in finish_call_expr.
Thanks for the suggestion. I spent some more time looking into the
related code. If I understand it correctly, I think this is just what
build_x_conditional_expr in ./cp/typeck.c does:
If the conditional expression is type-dependent in the template, it
builds and returns a COND_EXPR without TREE_TYPE.
If the conditional expression is not type-dependent, it calls
build_conditional_expr to determine its TREE_TYPE and then builds up
a COND_EXPR with the unconverted/original operands.
Different from CALL_EXPR, the TREE_TYPE of a COND_EXPR is determined
by the TREE_TYPEs of its latter two operands. When the types of the
two operands are different, a conversion is attempted on each operand
type to match the type of the other operand; while for a CALL_EXPR,
its TREE_TYPE is independent from the TREE_TYPE(s) of its arg(s).
So I think it is necessary for build_conditional_expr to call
convert_like_real to do the conversions. The parser should try its best
to determine the type and check for any semantic error for expressions
in a template declaration, especially for non-dependent expressions.
I still feel the proposed patch in
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00076.html
makes sense. But if you think anything is not appropriate or have any
more question, please do let me know.
Regards,
Yufeng