On 1/29/21 8:04 AM, Tom de Vries wrote: > On 1/28/21 3:08 PM, Tom Tromey wrote: >>>>>>> "Tom" == Tom de Vries writes: >> >> Tom> 2021-01-28 Tom de Vries >> >> 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? And FWIW, this WIP follow-up patch enables decimal float complex well enough to do "print (_Decimal32)0 + 5i". Thanks, - Tom