https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #6 from kargl at gcc dot gnu.org ---
(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).
