On 1/28/21 3:08 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> 2021-01-28  Tom de Vries  <tdevries@suse.de>
> 
> Tom> 	PR exp/27265
> Tom> 	* valarith.c (scalar_binop): Don't call complex_binop unless
> Tom> 	arguments are either complex or can be casted to complex.
> 
> Thanks for doing this.
> 
> Tom> +  if ((type1->code () == TYPE_CODE_COMPLEX
> Tom> +       && (type2->code () == TYPE_CODE_COMPLEX
> Tom> +	   || type2->code () == TYPE_CODE_INT
> Tom> +	   || type2->code () == TYPE_CODE_FLT))
> Tom> +      || ((type2->code () == TYPE_CODE_COMPLEX
> Tom> +	   && (type1->code () == TYPE_CODE_COMPLEX
> Tom> +	       || type1->code () == TYPE_CODE_INT
> Tom> +	       || type1->code () == TYPE_CODE_FLT))))
> Tom>      return complex_binop (arg1, arg2, op);
> 
> Maybe it should use is_floating_type || is_integral_type instead?
> is_scalar_type sounds like it should be right but does something really
> different instead.  That function looks suspect to me.
> 
> This approach would still rule out fixed point.  I'm not sure if that's
> ok to do though.
> 
> Also weirdly, is_fixed_point_type looks through TYPE_CODE_RANGE (seems
> reasonable) but is_integral_type does not (seems wrong).
> 

I managed to create an example using TYPE_CODE_BOOL that used to work
but was broken by this patch, added it to the tests in the patch.

I've now gone a different route: instead of trying to narrow down when
complex_binop can be called, detect the error situation in complex_bin
and throw an error.

That avoids speculation about what type is left after promotion.
Instead, we just check the type after promotion.

WDYT?

Thanks,
- Tom