[PATCH] Fix fallout from r219557

[Richard Smith]

On Tue, Dec 30, 2014 at 11:07 AM, Abramo Bagnara <abramo.bagnara at bugseng.com
> wrote:

> Il 11/11/2014 21:32, Richard Smith ha scritto:
>
> > This change is incorrect. The usual arithmetic conversions do *not*
> > take `(_Complex double, double)` to `(_Complex double, _Complex
> > double)`; note C11 6.13.1.8/1 ("... without change of type domain").
>
> I guess that this justify why after r219557 we don't have any longer a
> FloatingRealToComplex implicit cast for `c' in `b = c + b' below, right?
>
> _Complex float b;
>
> void foo (void)
> {
>   float c = 1.0;
>   b = c + b;
> }
>

That's correct.


> The puzzling thing is that we still generates implicit
> FloatingRealToComplex implicit cast for:
>
> _Complex float b;
>
> void foo (void)
> {
>   int c = 1;
>   b = c + b;
> }
>
> Is this a bug?
>

Yes, that's a bug. Note that this leads to us computing the wrong answer
here:

_Complex float a = __builtin_inf();
_Complex float b = a * 1;

(If you promote first, you get Inf + NaN i; otherwise, you get Inf + 0 i.)

I'm also wondering if it is a savy choice (standard apart) to omit such
> kind of implicit conversions from AST considering that indeed they
> "happens" (taken for granted we have also other implicit casts that
> standard does not strictly requires).


See example above. The implicit conversion does *not* actually "happen";
the mixed-mode multiplication does not compute the same result as promoting
to _Complex and then performing the computation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150114/d2600d85/attachment.html>