[PATCH] Fix fallout from r219557

[Anton Korobeynikov]

On Wed, Nov 12, 2014 at 12:18 AM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Tue, Nov 11, 2014 at 1:17 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>>
>> On Tue, Nov 11, 2014 at 12:49 PM, Anton Korobeynikov
>> <anton at korobeynikov.info> wrote:
>>>
>>> Just to make stuff clear.
>>>
>>> Currently we're building the following AST:
>>>
>>> ```
>>> `-FunctionDecl 0x7fc5b306d600 <line:4:1, line:7:1> line:4:5 main 'int
>>> (void)'
>>>   `-CompoundStmt 0x7fc5b306d940 <col:16, line:7:1>
>>>     |-ConditionalOperator 0x7fc5b306d8d0 <line:5:3, col:32> '_Complex
>>> long double'
>>>     | |-IntegerLiteral 0x7fc5b306d6f8 <col:3> 'int' 0
>>>     | |-CallExpr 0x7fc5b306d7a0 <col:7, col:17> 'long double'
>>>     | | |-ImplicitCastExpr 0x7fc5b306d788 <col:7> 'long double (*)(long
>>> double)' <FunctionToPointerDecay>
>>>     | | | `-DeclRefExpr 0x7fc5b306d718 <col:7> 'long double (long
>>> double)' Function 0x7fc5b3033e50 'sqrtl' 'long double (long double)'
>>>     | | `-ImplicitCastExpr 0x7fc5b306d7d0 <col:13> 'long double'
>>> <FloatingCast>
>>>     | |   `-FloatingLiteral 0x7fc5b306d740 <col:13> 'float' 2.000000e+00
>>>     | `-CallExpr 0x7fc5b306d870 <col:21, col:32> '_Complex long double'
>>>     |   |-ImplicitCastExpr 0x7fc5b306d858 <col:21> '_Complex long double
>>> (*)(_Complex long double)' <FunctionToPointerDecay>
>>>     |   | `-DeclRefExpr 0x7fc5b306d7e8 <col:21> '_Complex long double
>>> (_Complex long double)' Function 0x7fc5b3033b30 'csqrtl' '_Complex long
>>> double (_Complex long double)'
>>>     |   `-ImplicitCastExpr 0x7fc5b306d8b8 <col:28> '_Complex long double'
>>> <FloatingRealToComplex>
>>>     |     `-ImplicitCastExpr 0x7fc5b306d8a0 <col:28> 'long double'
>>> <FloatingCast>
>>>     |       `-FloatingLiteral 0x7fc5b306d810 <col:28> 'float'
>>> 2.000000e+00
>>>     `-ReturnStmt 0x7fc5b306d920 <line:6:3, col:10>
>>>       `-IntegerLiteral 0x7fc5b306d900 <col:10> 'int' 0
>>> ```
>>>
>>> The type of operator itself is correct.
>>
>>
>> For your testcase, but not in general. Try (0 ? csqrtl(2.0f) :
>> sqrtl(2.0f)) and you'll see we get the type of the ConditionalOperator
>> wrong.
>
>
> Err, (0 ? sqrtl(2.0f) : csqrtl(2.0f))
Yeah, right. This seems to be separate issue.

>>> However, the types of lhs and rhs do not match. Prior to r219557 there
>>> was additional ImplicitCastExpr to convert the result of sqrtl to _Complex
>>> long double.
>> I see; CheckConditionalOperator should be doing this. Use
>> ImpCastExprToType to convert the operands to the result type in the
>> arithmetic case, after picking the correct type (from the result of
>> UsualArithmeticConversions).
Ok.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University