https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680
--- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Mikael Morin from comment #3) > I thought the call to gfc_type_convert_binary in eval_intrinsic was taking > care of mismatching types, doesn't it? It does, and then it doesn't do it sometimes... For real, parameter :: x(*) = [real :: ([1])] ** 2.0 after adding breakpoints in gfc_type_convert_binary and arith_power, I see correct types in the former (e->value.op.op2->ts.type = BT_REAL) but incorrect types in the latter (op1->ts.type = BT_INTEGER). It seems to be the ratatouille of parentheses, array constructors, typespec, and arithmetic operation that is crucial to get this type of error. In 12-branch, I also see other bad things happening, which I believe have partially been fixed by the series of patches for pr107000 and friends. Try: print *, [integer :: ([3.0])] ** 2.0 This gives 0.00000000 for all versions <= 12, and 9.00000000 for mainline. Given these observations, I suspect that typespecs are not consistently handled... See also the previous discussions.
