[Bug fortran/109641] New: Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[Bug fortran/109641] New: Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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

            Bug ID: 109641
           Summary: Gfortran fails to overload intrinsic operator (*) if
                    operands are complex. It works with real ones.
           Product: gcc
           Version: og10 (devel/omp/gcc-10)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adelson.oliveira at gmail dot com
  Target Milestone: ---

Created attachment 54929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54929&action=edit
A small FORTRAN code to reproduce the bug

I'm uploading a small fortran code to show the problem. The code has a module
that overloads intrinsic operator (*) for a vector matrix multiplication. The
bug is triggered when the matrix (and the result) is complex.
The compilation with

$ gfortran -o teste -O teste.f90

will fail with a error message reporting inconsistent rank declaration.
As indicated in the snippet, simply changing  from COMPLEX to REAL in the
declaration of the matrix (and the result) everything goes fine.

As an additional information, if one changes from the intrinsic (*) to
something like (.MULT.) in the module then there is no error at all.

Please look for the comments in the MODULE TESTEOP and in the PROGRAM TESTE to
better test  the bug.

Thanks for any help

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |rejects-valid
                 CC|                            |anlauf at gcc dot gnu.org
   Last reconfirmed|                            |2023-04-27
     Ever confirmed|0                           |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

NAG, Intel and Nvidia accept the code.

Funny that REAL*REAL is recognized, but not REAL*COMPLEX ...

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid

--- Comment #2 from anlauf at gcc dot gnu.org ---
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.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Untested patch:

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 02028f993fd..d70b4872162 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -986,6 +986,14 @@ gfc_type_convert_binary (gfc_expr *e, int wconversion)
       goto done;
     }

+  gfc_expression_rank (op1);
+  gfc_expression_rank (op2);
+  if (op1->rank > 0 && op2->rank && (op1->rank != op2->rank))
+    {
+      gfc_clear_ts (&e->ts);
+      return;
+    }
+
   /* Real combined with complex.  */
   e->ts.type = BT_COMPLEX;
   if (op1->ts.kind > op2->ts.kind)

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> Untested patch:

Unfortunately this regresses on many testcases :-(

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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

--- Comment #5 from Adelson Oliveira <adelson.oliveira at gmail dot com> ---
(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.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[kargl at gcc dot gnu.org]

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).

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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

--- Comment #8 from Adelson Oliveira <adelson.oliveira at gmail dot com> ---
Then I should have defined the operations with double precision as well?

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Apr 28, 2023 at 01:37:48AM +0000, adelson.oliveira at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
> 
> --- Comment #8 from Adelson Oliveira <adelson.oliveira at gmail dot com> ---
> Then I should have defined the operations with double precision as well?
> 

I have tested, but mostly yes.  If I do a -fdump-parse-tree
of your code, I see

  code:
  ASSIGN teste:v(FULL) 1.00000000e0
  ASSIGN teste:m(FULL) (complex 1.00000000e0 1.00000000e0)
  ASSIGN teste:r(FULL) (* __convert_r4_c4[[((teste:v(FULL)))]] teste:m(FULL))

If you have mixed REAL and DOUBLE PRECISION, you'll likely
have an implicit __convert_r4_r8.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 54954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54954&action=edit
Patch (2nd try)

This one works and regtests ok.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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

--- Comment #11 from Adelson Oliveira <adelson.oliveira at gmail dot com> ---
I'm a linux user and gfortran comes with my distro. I mean, I did not compile
gcc.
Is this patch still to be tested? Am I expected to do something to test it? Or
I just wait until a new gfortran version is released?

Thanks for the attention in the bug.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Adelson Oliveira from comment #11)
> I'm a linux user and gfortran comes with my distro. I mean, I did not
> compile gcc.
> Is this patch still to be tested? Am I expected to do something to test it?

No, this is more a proof-of-concept how to fix the issue.  It is incomplete,
as it does not yet handle all intrinsic binary operators (e.g. ==, /= need
to be handled as well).

> Or I just wait until a new gfortran version is released?

Once a fix is pushed, you could try to compile gcc yourself, because it may
take some time distros pick up the fixed gcc versions.

For the time being, you can still use .MULT. etc. as a portable workaround.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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

--- Comment #13 from Adelson Oliveira <adelson.oliveira at gmail dot com> ---
Thanks, anlauf


Em sáb., 29 de abr. de 2023 às 16:00, anlauf at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> escreveu:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
>
> --- Comment #12 from anlauf at gcc dot gnu.org ---
> (In reply to Adelson Oliveira from comment #11)
> > I'm a linux user and gfortran comes with my distro. I mean, I did not
> > compile gcc.
> > Is this patch still to be tested? Am I expected to do something to test
> it?
>
> No, this is more a proof-of-concept how to fix the issue.  It is
> incomplete,
> as it does not yet handle all intrinsic binary operators (e.g. ==, /= need
> to be handled as well).
>
> > Or I just wait until a new gfortran version is released?
>
> Once a fix is pushed, you could try to compile gcc yourself, because it may
> take some time distros pick up the fixed gcc versions.
>
> For the time being, you can still use .MULT. etc. as a portable workaround.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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

--- Comment #14 from Adelson Oliveira <adelson.oliveira at gmail dot com> ---
Ok, thanks.

Em sáb., 29 de abr. de 2023 11:55 PM, <gcc-bugzilla@gcc.gnu.org> escreveu:

> Attachments with a MIME type of "text/html" are not allowed on this
> installation.
>
> Adelson Oliveira wrote:
> > Thanks, anlauf
> >
> >
> > Em sáb., 29 de abr. de 2023 às 16:00, anlauf at gcc dot gnu.org <
> > gcc-bugzilla@gcc.gnu.org> escreveu:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
> > >
> > > --- Comment #12 from anlauf at gcc dot gnu.org ---
> > > (In reply to Adelson Oliveira from comment #11)
> > > > I'm a linux user and gfortran comes with my distro. I mean, I did not
> > > > compile gcc.
> > > > Is this patch still to be tested? Am I expected to do something to
> test
> > > it?
> > >
> > > No, this is more a proof-of-concept how to fix the issue.  It is
> > > incomplete,
> > > as it does not yet handle all intrinsic binary operators (e.g. ==, /=
> need
> > > to be handled as well).
> > >
> > > > Or I just wait until a new gfortran version is released?
> > >
> > > Once a fix is pushed, you could try to compile gcc yourself, because
> it may
> > > take some time distros pick up the fixed gcc versions.
> > >
> > > For the time being, you can still use .MULT. etc. as a portable
> workaround.
> > >
> > > --
> > > You are receiving this mail because:
> > > You reported the bug.
>

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org

--- Comment #15 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-May/059246.html

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:185da7c2014ba41f38dd62cc719873ebf020b076

commit r14-529-g185da7c2014ba41f38dd62cc719873ebf020b076
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Fri May 5 21:22:12 2023 +0200

    Fortran: overloading of intrinsic binary operators [PR109641]

    Fortran allows overloading of intrinsic operators also for operands of
    numeric intrinsic types.  The intrinsic operator versions are used
    according to the rules of F2018 table 10.2 and imply type conversion as
    long as the operand ranks are conformable.  Otherwise no type conversion
    shall be performed to allow the resolution of a matching user-defined
    operator.

    gcc/fortran/ChangeLog:

            PR fortran/109641
            * arith.cc (eval_intrinsic): Check conformability of ranks of
operands
            for intrinsic binary operators before performing type conversions.
            * gfortran.h (gfc_op_rank_conformable): Add prototype.
            * resolve.cc (resolve_operator): Check conformability of ranks of
            operands for intrinsic binary operators before performing type
            conversions.
            (gfc_op_rank_conformable): New helper function to compare ranks of
            operands of binary operator.

    gcc/testsuite/ChangeLog:

            PR fortran/109641
            * gfortran.dg/overload_5.f90: New test.

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:611be07e48956c8b7371eb580eef124990114fd3

commit r13-7353-g611be07e48956c8b7371eb580eef124990114fd3
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Fri May 5 21:22:12 2023 +0200

    Fortran: overloading of intrinsic binary operators [PR109641]

    Fortran allows overloading of intrinsic operators also for operands of
    numeric intrinsic types.  The intrinsic operator versions are used
    according to the rules of F2018 table 10.2 and imply type conversion as
    long as the operand ranks are conformable.  Otherwise no type conversion
    shall be performed to allow the resolution of a matching user-defined
    operator.

    gcc/fortran/ChangeLog:

            PR fortran/109641
            * arith.cc (eval_intrinsic): Check conformability of ranks of
operands
            for intrinsic binary operators before performing type conversions.
            * gfortran.h (gfc_op_rank_conformable): Add prototype.
            * resolve.cc (resolve_operator): Check conformability of ranks of
            operands for intrinsic binary operators before performing type
            conversions.
            (gfc_op_rank_conformable): New helper function to compare ranks of
            operands of binary operator.

    gcc/testsuite/ChangeLog:

            PR fortran/109641
            * gfortran.dg/overload_5.f90: New test.

    (cherry picked from commit 185da7c2014ba41f38dd62cc719873ebf020b076)

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |13.2
         Resolution|---                         |FIXED

--- Comment #18 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-14, and backported to 13-branch.  Closing.

Thanks for the report!

[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.

[adelson.oliveira at gmail dot com]

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

--- Comment #19 from Adelson Oliveira <adelson.oliveira at gmail dot com> ---
Thank you all

Em qui., 18 de mai. de 2023 às 14:01, anlauf at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> escreveu:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641
>
> anlauf at gcc dot gnu.org changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|ASSIGNED                    |RESOLVED
>    Target Milestone|---                         |13.2
>          Resolution|---                         |FIXED
>
> --- Comment #18 from anlauf at gcc dot gnu.org ---
> Fixed on mainline for gcc-14, and backported to 13-branch.  Closing.
>
> Thanks for the report!
>
> --
> You are receiving this mail because:
> You reported the bug.