From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id B237E3858C60; Fri, 28 Apr 2023 01:15:14 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B237E3858C60
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682644514;
	bh=iPt5NIiSIES0p9C4LpPc/sEFbtMb0V0aQCRB4BFa63c=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=DiSp5m/wr03yIqZrbEfKXtJDfcsfxSWcCM6XuVqQ/W44st/4J6RQllKcxwGuhkmfK
	 x/Fe5cUSNJtpCesLCP1tf2tgJeUDmoa24OfrjFgUh6fiF9vAQ22fF5/7YRisGxni7B
	 glFBFMMhyPSdsz++CURJOD6hbG7D2ECa0GsufJ8A=
From: "kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/109641] Gfortran fails to overload intrinsic operator
 (*) if operands are complex. It works with real ones.
Date: Fri, 28 Apr 2023 01:15:13 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 10.1.0
X-Bugzilla-Keywords: accepts-invalid, rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kargl at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-109641-4-vsimsLIBUA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109641-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109641-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109641

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
> >=20
> >   FUNCTION MULTc4(v,m)
> >     REAL,    INTENT(IN) :: v(:)
> >=20
> > by
> >=20
> >     complex, INTENT(IN) :: v(:)
> >=20
> > makes the code compile, but should not.  And the fortran-dump appears to
> > explain why: we prematurely convert the first argument in the expression
> >=20
> >   r=3Dv*m
> >=20
> > from real to complex, so we resolve to the wrong specific.
> > This also explains why real*real does not exhibit this problem.
>=20
> 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).=