Bug 31298 - [F03] use mod, operator(+) => operator(.userOp.) not supported
Summary: [F03] use mod, operator(+) => operator(.userOp.) not supported
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: rejects-valid
Depends on: 33072
Blocks: F2003
  Show dependency treegraph
Reported: 2007-03-21 15:15 UTC by Tobias Burnus
Modified: 2018-04-18 19:01 UTC (History)
6 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2007-03-28 02:39:22

Preliminary patch (796 bytes, patch)
2007-03-31 22:51 UTC, Tobias Burnus
Details | Diff
Updated patch (829 bytes, patch)
2007-04-15 20:20 UTC, Tobias Burnus
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2007-03-21 15:15:29 UTC
valgrind finds when compiling gfortran.dg/use_6.f90
the following unitinitalized variables:

==29473== Conditional jump or move depends on uninitialised value(s)
==29473==    at 0x43DD76: read_module (module.c:733)
==29473==    by 0x43E664: gfc_use_module (module.c:4201)
==29473==    by 0x443DC7: accept_statement (parse.c:1256)
==29473==    by 0x444854: parse_spec (parse.c:1902)
==29473==    by 0x445C95: parse_progunit (parse.c:2901)
==29473==    by 0x445F01: gfc_parse_file (parse.c:3239)
==29473==    by 0x46423D: gfc_be_parse_file (f95-lang.c:307)
==29473==    by 0x679573: toplev_main (toplev.c:1050)
==29473==    by 0x52BE943: (below main) (in /lib64/libc-2.5.so)

Analogusly for use_5.f90.
Comment 1 Jerry DeLisle 2007-03-28 02:39:22 UTC
I will try this one.
Comment 2 Jerry DeLisle 2007-03-28 04:21:37 UTC
Valgrind gives no error related to uninitialized when compiling with gfortran.

I am not sure this is a problem of real concern.
Comment 3 Tobias Burnus 2007-03-31 22:51:21 UTC
Created attachment 13312 [details]
Preliminary patch

> Valgrind gives no error related to uninitialized when compiling with gfortran.

I think you are using:
  valgrind gfortran use_6.f90
this does not work as "gfortran" is only a wrapper program. You need to call
  valgrind /..../4.3.0/f951 use_6.f90 ...
as the problem is in f951.

The error is in the line:
          if (type == INTERFACE_USER_OP)
            new->operator = operator;
of module.c's gfc_match_use as - contrary to my expectation - gfc_match_generic_spec does not initialize operator for type == INTERFACE_USER_OP.

Attached: First draft of a patch, which fixes:
a) Uninitialized variable
b) Better error message for  operator(.foo.) => operator(.gt.)
(use-defined-operator shall not identify a generic-binding, C1111/R1111)
c) Allow  operator(.gt.) => operator(.foo.)

(c) is not working and gives error messages such as:
  Operands of comparison operator '.gt.' at (1) are TYPE(bar)/TYPE(bar)

(Could someone check whether I read C1111/R1111 (in Section 11.2.1 of the Fortran 2003 standard) correctly that .gt.=>.foo. is allowed and .foo. => .gt. forbidden? As both g95 and NAG f95 do not seem to support renaming of operators, I can not even check what other compilers are doing.)
Comment 4 Tobias Burnus 2007-04-15 20:20:24 UTC
Created attachment 13369 [details]
Updated patch

This patch handles almost everything except of
  operator(<intrinsic>) => operator(.user.)
where <intrinsic> could be e.g. ".gt." or "-" or ...
One probably needs also a check whether the user operator is an unary or binary operator, which should match the intrinsic operator.

Difference to previous patch:
 allow:    "use mod, only:  assignment(=)"
 disallow: "use mod, only:  assignment(=) => operator(.user.)
(Before the former one was rejected and the latter accepted.)

As collateral damage it seems to fix PR 29876. (At least I get a proper error message with this patch and no error message for .none. without this patch [which is different to the reported behaviour.])
Comment 5 Tobias Burnus 2007-04-18 10:18:25 UTC
(In reply to comment #4)
Another thing which needs to be supported:
  use mod, only: operator(foo) => operator(.op.), &
                 operator(bar) => operator(.op.), &
                 operator(op), &
                 operator(+) => operator(.op.)

namely: importing the same operator under different names.
Comment 6 Francois-Xavier Coudert 2007-05-22 13:31:44 UTC
Tobias, what is the current status on that bug?
Comment 7 Tobias Burnus 2007-05-22 13:45:29 UTC
(In reply to comment #6)
> Tobias, what is the current status on that bug?
The attached patch is ok, except it fixes only part of the problem.

I got stuck at:
   operator(+) => operator(.op.)
That is: importing an user operator as intrinsic operator. I have several versions of patches here, which all don't work.
Comment 8 Tobias Burnus 2007-06-23 13:41:10 UTC
Issue which could be solved by the fix for this PR: PR 29876.
Comment 9 Tobias Burnus 2007-08-14 21:16:57 UTC
Comment on attachment 13369 [details]
Updated patch

> strcpy (new->local_name, name);
This does not make much sense for INTERFACE_INTRINSIC_OP.

The problem with being able to import an operator only once is related to PR 33072: operator(.op.), operator(.my.)=>operator(.op) gives an error while operator(.modproc.),operator(.my.)=>operator(.modproc.)
is found. (.op. should be "interface operator(.op.)" and "modproc" can be any module procedure.)
Comment 10 Tobias Burnus 2007-08-17 08:14:04 UTC
Rejecting "operator(.procedure.)" has been fixed by PR33072.
Accepting multiple renames/imports of an operator ("operator(.op.), operator(.myop.)=>operator(.op.)") is fixed by the submitted patch http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01081.html

Remains to be done:
Supporting "operator(+)=>operator(.myPlusOp.)", which can be based on the attachment 13369 [details] and the submitted patch.
Comment 11 patchapp@dberlin.org 2007-08-17 15:10:33 UTC
Subject: Bug number PR31298

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01081.html
Comment 12 Tobias Burnus 2007-08-26 18:37:36 UTC
Subject: Bug 31298

Author: burnus
Date: Sun Aug 26 18:37:23 2007
New Revision: 127812

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127812
2007-08-26  Tobias Burnus  <burnus@net-b.de>

	PR fortran/31298
	* module.c (mio_symbol_ref,mio_interface_rest):  Return pointer_info.
	(load_operator_interfaces): Support multible loading of an operator.

2007-08-26  Tobias Burnus  <burnus@net-b.de>

	PR fortran/31298
	* gfortran.dg/use_10.f90: New.


Comment 13 Tobias Burnus 2007-08-26 18:43:22 UTC
REMAINING:  operator(generic opterator) => operator(user operator)
e.g.  operator(+) => operator(.myplus.)
For obvious reasons the reversed is not allowed (MR&C claims that also the former is invalid, but I think they err.)

Starting point could be the attachment #13369 [details] and something enhancement of the previous patch.
Comment 14 Tobias Burnus 2008-01-15 15:21:45 UTC
Check that the renamed imported operator is not imported again, see PR 33541.

If I recall correctly, this part is missing for the patch in PR 33541
Comment 15 Richard Biener 2008-03-14 16:45:57 UTC
Shouldn't have a target milestone (no regression and not fixed)
Comment 16 Dominique d'Humieres 2013-06-22 16:59:37 UTC
Should not this PR be closed as FIXED (no activity for the past five years)?
Comment 17 Tobias Burnus 2013-06-22 17:26:06 UTC
(In reply to Dominique d'Humieres from comment #16)
> Should not this PR be closed as FIXED (no activity for the past five years)?

Of course not. It's still not implemented. By that argument, we could also close bugs about UTIO or submodules as FIXED because they haven't be implemented either.
Comment 18 Jürgen Reuter 2018-01-05 10:43:41 UTC
Contrary to what Tobias Burnus claimed, I think this case is indeed forbidden. Section 11.2.2 of the Fortran 2003 status (version from Apr 27, 2010) says in R1111 for rename: local-name => use-name or OPERATOR(local-defined-operator) => OPERATOR (use-defined-operator). R1114 says that local-defined-operator is defined-unary-op or defined-binary-op, and Sec. with C703 says that defined-unary-op shall not contain more than 63 letters and shall not be the same as any intrinsic-operator or logical-literal-constant. Sec. (C704) says the same for defined-binary-op. This would preclude the example give in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298#c13 by Tobias Burnus. ifort vetoes such a construction with the message "error #8007: Intrinsic operator can not be used as the name of a locally defined operator in an OPERATOR rename clause." [This error, however, is not further documented: https://software.intel.com/en-us/articles/fdiag8007  ]
Comment 19 janus 2018-04-18 19:01:14 UTC
(In reply to Jürgen Reuter from comment #18)
> Contrary to what Tobias Burnus claimed, I think this case is indeed
> forbidden.

I agree with Jürgen's assessment in comment #18 that use-renaming of operators may not involve any intrinsic operators, which is also supported by ifort 18 and MR&C (as noted by Tobias in comment #13).

Here is a simple test case that is accepted by ifort and gfortran as is (and rejected by both when uncommenting the commented line):

module m

  interface operator(.myplus.)
    procedure add
  end interface


  integer function add(a, b)
    integer, intent(in) :: a,b
    add = abs(a) + abs(b)
  end function

end module

program p
! use m, only: operator(+) => operator(.myplus.)  ! forbidden
use m, only: operator(.otherplus.) => operator(.myplus.)
print *, -1 .otherplus. -2

So: Let's finally close this PR ...