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.
I will try this one.
Valgrind gives no error related to uninitialized when compiling with gfortran.
I am not sure this is a problem of real concern.
Created attachment 13312 [details]
> 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.)
Created attachment 13369 [details]
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.])
(In reply to comment #4)
Another thing which needs to be supported:
use mod, only: operator(foo) => operator(.op.), &
operator(bar) => operator(.op.), &
operator(+) => operator(.op.)
namely: importing the same operator under different names.
Tobias, what is the current status on that bug?
(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.
Issue which could be solved by the fix for this PR: PR 29876.
Comment on attachment 13369 [details]
> 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.)
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.
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
Subject: Bug 31298
Date: Sun Aug 26 18:37:23 2007
New Revision: 127812
2007-08-26 Tobias Burnus <firstname.lastname@example.org>
* 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 <email@example.com>
* gfortran.dg/use_10.f90: New.
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.
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
Shouldn't have a target milestone (no regression and not fixed)
Should not this PR be closed as FIXED (no activity for the past five years)?
(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.
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. 22.214.171.124 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. 126.96.36.199 (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 ]
(In reply to Jürgen Reuter from comment #18)
> Contrary to what Tobias Burnus claimed, I think this case is indeed
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):
integer function add(a, b)
integer, intent(in) :: a,b
add = abs(a) + abs(b)
! 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 ...