[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