https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
--- Comment #7 from Adelson Oliveira <adelson.oliveira at gmail dot com> --- (In reply to kargl from comment #6) > (In reply to Adelson Oliveira from comment #5) > > (In reply to anlauf from comment #2) > > > Replacing the first argument of > > > > > > FUNCTION MULTc4(v,m) > > > REAL, INTENT(IN) :: v(:) > > > > > > by > > > > > > complex, INTENT(IN) :: v(:) > > > > > > makes the code compile, but should not. And the fortran-dump appears to > > > explain why: we prematurely convert the first argument in the expression > > > > > > r=v*m > > > > > > from real to complex, so we resolve to the wrong specific. > > > This also explains why real*real does not exhibit this problem. > > > > Interesting! But I wonder why simply changing the intrinsic operator (*) to > > something different, say (.MULT.) there is no error at all no matter one > > uses complex or real. > > The simple and obvious answer is that .multi. is not an intrinsic > operator that your trying to overload while * is an intrinsic > operator that you have overloaded. What Harald has found with the > type conversion, likely means that gfortran thinks that your generic > interface does not apply because it does not include > > multcc(v,m) > complex, intent(in) :: v(:) > complex, intent(in) :: m(:,:) > ... > > since your overloaded operator doesn't have multcc, gfortran > assumes that * is the intrinsic operator and issues the correct > error. In fact, I just add multcc to your example code and it > compiles and runs without a problem. > > Note, the Fortran standard has language to ensure that an ambiguity > does not arise when overloading. > > If the operator is an intrinsic-operator(R608), the number of dummy > arguments shall be consistent with the intrinsic uses of that operator, > and the types, kind type parameters, or ranks of the dummy arguments > shall differ from those required for the intrinsic operation (10.1.5). Great! I see now.
