[Bug fortran/31298] New: Uninitialized variable in f951 (in read_module)

[Bug fortran/31298] New: Uninitialized variable in f951 (in read_module)

[burnus at gcc dot gnu dot org]

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.


-- 
           Summary: Uninitialized variable in f951 (in read_module)
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module)

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2007-03-28 02:39 -------
I will try this one.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-03-28 02:39:22
               date|                            |


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module)

[jvdelisle at gcc dot gnu dot org]

------- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-03-28 04:21 -------
Valgrind gives no error related to uninitialized when compiling with gfortran.

I am not sure this is a problem of real concern.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module)

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2007-03-31 22:51 -------
Created an attachment (id=13312)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13312&action=view)
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.)


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jvdelisle at gcc dot gnu dot|burnus at gcc dot gnu dot
                   |org                         |org


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module)

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2007-04-15 20:20 -------
Created an attachment (id=13369)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13369&action=view)
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.])


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #13312|0                           |1
        is obsolete|                            |


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module)

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2007-04-18 10:18 -------
(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.


-- 


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module)

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2007-05-22 13:31 -------
Tobias, what is the current status on that bug?


-- 


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module)

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2007-05-22 13:45 -------
(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.


-- 


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module) / renaming operator in USE

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2007-06-23 13:41 -------
Issue which could be solved by the fix for this PR: PR 29876.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Uninitialized variable in   |Uninitialized variable in
                   |f951 (in read_module)       |f951 (in read_module) /
                   |                            |renaming operator in USE


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

[Bug fortran/31298] Uninitialized variable in f951 (in read_module) / renaming operator in USE

[burnus at gcc dot gnu dot org]

------- Comment #9 from burnus at gcc dot gnu dot org  2007-08-14 21:16 -------
(From update of attachment 13369)
> 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.)


-- 


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2007-08-17 08:14 -------
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 and the submitted patch.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |rejects-valid
            Summary|Uninitialized variable in   |F2003: use mod, operator(+)
                   |f951 (in read_module) /     |=> operator(.userOp.) not
                   |renaming operator in USE    |supported
   Target Milestone|---                         |4.3.0


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[patchapp at dberlin dot org]

------- Comment #11 from patchapp at dberlin dot org  2007-08-17 15:10 -------
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


-- 


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[burnus at gcc dot gnu dot org]

------- Comment #12 from burnus at gcc dot gnu dot org  2007-08-26 18:37 -------
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
Log:
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.


Added:
    trunk/gcc/testsuite/gfortran.dg/use_10.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[burnus at gcc dot gnu dot org]

------- Comment #13 from burnus at gcc dot gnu dot org  2007-08-26 18:43 -------
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 and something enhancement of the
previous patch.


-- 


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[burnus at gcc dot gnu dot org]

------- Comment #14 from burnus at gcc dot gnu dot org  2008-01-15 15:21 -------
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


-- 


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2008-03-14 16:45 -------
Shouldn't have a target milestone (no regression and not fixed)


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.0                       |---


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

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


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

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(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.

[Bug fortran/31298] F2003: use mod, operator(+) => operator(.userOp.) not supported

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Should not this PR be closed as FIXED (no activity for the past five years)?