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
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.
(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
(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.
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.
(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?
Created attachment 13243 [details] 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.
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
Fixed, thanks Joost for the report!