> 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
