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 9B3363858CDA; Fri, 28 Apr 2023 01:35:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9B3363858CDA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682645752;
	bh=LOYapRDC6JGJyu6fvV83ypWWLKONfVUmekpp20xIeCU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=vSxXBdGr+D2llHRsv4glNr/VzQGwTU5wTukUVQAVQPnBslgQR9vy0ORJnU/X8oon6
	 4s+uCajNx6G82c3Im7X7KmeJzTvNacBik4wadeW5dsxWd0M69SVRd6g030XSuviEYc
	 kN/DID1N2Q408hL9MI0R9nKzTVDI2idW5As+QrI4=
From: "adelson.oliveira at gmail dot com" <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:35:52 +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: adelson.oliveira at gmail dot com
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: 
Message-ID: <bug-109641-4-UB3fZEJmi7@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

--- 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
> > >=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 express=
ion
> > >=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.
>=20
> 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
>=20
>   multcc(v,m)
>     complex, intent(in) :: v(:)
>     complex, intent(in) :: m(:,:)
>     ...
>=20
> 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.
>=20
> Note, the Fortran standard has language to ensure that an ambiguity
> does not arise when overloading.
>=20
>    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.=