[Bug fortran/30877] New: incorrect error message for valid code

[Bug fortran/30877] New: incorrect error message for valid code

[jv244 at cam dot ac dot uk]

With recent trunk, gfortran incorrectly generates an error for the following
standard code:
MODULE M1
 INTERFACE OPERATOR(*)
  MODULE PROCEDURE F1
 END INTERFACE
CONTAINS
 FUNCTION F1(a,b) RESULT (c)
  COMPLEX, dimension(2,2), INTENT(IN) :: a
  COMPLEX, dimension(2), INTENT(IN)   :: b
  COMPLEX, dimension(2)   :: c
  c=matmul(a,b)
 END FUNCTION F1
END MODULE M1

USE M1
COMPLEX, dimension(2,2) :: a
COMPLEX, dimension(2)   :: b
COMPLEX, dimension(2)   :: c
a=0 ; b=0
c=a*b
END


-- 
           Summary: incorrect error message for valid code
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] overloading "operator(*)" for intrinsic type (complex) fails

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-02-20 16:32 -------
  MODULE PROCEDURE F1
                    1
Error: Operator interface at (1) conflicts with intrinsic interface

In other words:
overloading  "operator(*)"  for intrinsic type (i.e. "complex") fails.

Compiles with ifort, nagf95, g95.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
            Summary|incorrect error message for |overloading  "operator(*)"
                   |valid code                  |for intrinsic type (complex)
                   |                            |fails


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] overloading "operator(*)" for intrinsic type (complex) fails

[pault at gcc dot gnu dot org]

------- Comment #2 from pault at gcc dot gnu dot org  2007-02-21 21:14 -------
(In reply to comment #1)
>   MODULE PROCEDURE F1

interface.c:567 is where it all starts.  The types that cannot be over-ridden
are to be found there.  If complex is excluded from product, we run into a
problem with the test for the shape of the two operands.  Making them the same,
pro temp, permits the code to compile and run.

Paul 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] overloading "operator(*)" for intrinsic type (complex) fails

[ben_ship at lycos dot com]

------- Comment #3 from ben_ship at lycos dot com  2007-02-22 01:35 -------
(In reply to comment #1)

> In other words:
> overloading  "operator(*)"  for intrinsic type (i.e. "complex") fails.

Also for other intrinsic types e.g. "real". 
I don't think this is complex specific.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] overloading "operator(*)" for intrinsic type (complex) fails

[ben_ship at lycos dot com]

------- Comment #4 from ben_ship at lycos dot com  2007-02-22 03:16 -------
This might actually be a more general issue with operator overloading.

In this example the overloading of an operator that works on two different
shaped operands of intrinsic types is not allowed. At the same time 
there is no know conflicting operator (*) for generating the product 
"a*b" and you cannot define one without either

- changing "COMPLEX" to some derived type with complex elements, 
  therefore removing the type issue.

- replacing "*" with some user defined operator, e.g.".times.", rather than
overloading. (but then precedence is an issue)

I think it is a little unusual that COMPLEX is used rather than some derived
type.  However, ifort and g95 will compile this code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] overloading "operator(*)" for intrinsic type (complex) fails

[fxcoudert at gcc dot gnu dot org]

------- Comment #5 from fxcoudert at gcc dot gnu dot org  2007-03-21 00:10 -------
(In reply to comment #2)
> interface.c:567 is where it all starts.

Thanks for the pointer.

> If complex is excluded from product, we run into a
> problem with the test for the shape of the two operands.

I think it's the right way to go, though. I don't have the standard with me,
but I think it's precisely because of the different shapes that we can override
this. Maybe some code later in the codepath needs to be taught about that?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] Extending intrinsic operators

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |accepts-invalid
      Known to fail|                            |4.1.3 4.2.0 4.3.0
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-21 14:02:12
               date|                            |
            Summary|overloading  "operator(*)"  |Extending intrinsic
                   |for intrinsic type (complex)|operators
                   |fails                       |
   Target Milestone|---                         |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] Extending intrinsic operators

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-03-21 14:50 -------
Created an attachment (id=13243)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13243&action=view)
Patch to fix the problem reported

This one is mine. Attached patch (regtested on i686-linux) fixes the failure
and, as far as I see, should bring the extension of intrinsic operators
completely in line with the standards. I still need to come up with a complete
testcase to ensure that I haven't forgotten something along the way.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] Extending intrinsic operators

[fxcoudert at gcc dot gnu dot org]

------- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-03-25 11:01 -------
Subject: Bug 30877

Author: fxcoudert
Date: Sun Mar 25 10:01:23 2007
New Revision: 123196

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123196
Log:
        PR fortran/30877

        * fortran/interface.c (check_operator_interface): Implement
        the standard checks on user operators extending intrinsic operators.
        * fortran/resolve.c (resolve_operator): If the ranks of operators
        don't match, don't error out but try the user-defined ones first.

        * gfortran.dg/operator_1.f90: New test.
        * gfortran.dg/operator_2.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/operator_1.f90
    trunk/gcc/testsuite/gfortran.dg/operator_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877

[Bug fortran/30877] Extending intrinsic operators

[fxcoudert at gcc dot gnu dot org]

------- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-03-25 11:02 -------
Fixed, thanks Joost for the report!


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30877