Bug 13615 - -Wuninitialized produces wrong error message for characters
-Wuninitialized produces wrong error message for characters
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.2.0
: P2 minor
: ---
Assigned To: Not yet assigned to anyone
: diagnostic
Depends on: 12456
Blocks: 19276 Wuninitialized
  Show dependency treegraph
 
Reported: 2004-01-08 15:41 UTC by Kirill Smelkov
Modified: 2013-08-25 13:58 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-11-21 18:58:59


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill Smelkov 2004-01-08 15:41:28 UTC
g77 should warn that 'c' might be used uninitialized, while the same code templated 
with character changed to integer or 'double precision' generates the warning. 
 
 
----test_uninitialized.f------------------------- 
c g77 -Wuninitialized -c -O  test_uninitialized.f  
c test_uninitialized.f: In subroutine `warn_integer': 
c test_uninitialized.f:15: warning: `a' might be used uninitialized in this function 
c 
c *** THERE IS NO *** 
c test_uninitialized.f:29: warning: `c' might be used uninitialized ... 
 
c     says that a might be used uninitialized 
      subroutine warn_integer 
      implicit none 
 
      integer b 
      common /xxx/ b 
 
      integer a 
 
      b = a 
      end 
 
 
c     should say that a might be used uninitialized, 
c     but doesn't! 
      subroutine warn_character 
      implicit none 
 
      character d 
      common /yyy/ d 
 
      character c 
 
      d = c 
      end 
----------------- 
 
[kirr@roro Si2O7H6.molcas]$ g77 -v 
Reading specs from /mnt/tmini/kirr/local/gcc-3.3.2/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs 
Configured with: ../gcc-3.3.2/configure --prefix=/mnt/tmini/kirr/local/gcc-3.3.2 --with-gnu-as 
--with-gnu-ld --enable-threads=posix --enable-languages=c,c++,f77 --enable-checking 
--disable-nls 
Thread model: posix 
gcc version 3.3.2
Comment 1 Andrew Pinski 2004-01-08 18:26:33 UTC
I can reproduce this on 3.4, I have not tried gfortran on the tree-ssa yet.
Comment 2 Dara Hazeghi 2004-01-25 18:04:21 UTC
gfortran gives...

bash-2.05b$ dara/gcc-3.5-tree-ssa/bin/gfortran -Wuninitialized foo.f 
f951: warning: -Wuninitialized is not supported without -O
foo.f: In function `warn_character':
foo.f:23: fatal error: gfc_todo: Not Implemented: CHARACTER inside COMMON block or 
EQUIVALENCE list
compilation terminated.
Comment 3 Andrew Pinski 2004-04-26 04:24:54 UTC
The reason why it does not complain is that STRING(N:N) is not folded to be just an 
access.

;; Function warn_character (warn_character__)

warn_character ()
{
  int1 c[1];

<bb 0>:
  _gfortran_copy_string (1, &yyy.d, 1, &c);
  return;

}
Comment 4 Tobias Schlüter 2004-05-16 19:03:13 UTC
To make this clear: the ICE in gfortran is gone. It still doesn't give the
diagnostic, though.
Comment 5 Andrew Pinski 2004-05-18 18:29:36 UTC
After a fix (which is semi-broken) for PR 12456, the problem now is that characters in common blocks 
are stored as arrays.
Comment 6 Andrew Pinski 2006-01-09 04:29:40 UTC
This is basicially fixed now after PR 12456:
t.f: In function 'warn_integer':
t.f:19: warning: 'a' is used uninitialized in this function
'c[1]{lb: 1 sz: 1}t.f: In function 'warn_character':
t.f:33: warning: ' is used uninitialized in this function


But there is only a diagnostic issue now and not just a missed optimization.
Comment 7 Paul Thomas 2006-06-01 08:17:51 UTC
This is still the case; Is this a gfortran issue or a gcc one?

If I give the characters length, using any format, even the anonymous warning goes away.  In fact, any array expression that I have tried is the same; eg.

      real d(8), c(8) 
      d = c 

is ignored.

Paul
Comment 8 Francois-Xavier Coudert 2007-11-21 18:58:59 UTC
$ cat z.f
      subroutine warn_character(d)
      character c, d
      d = c
      end
$ gfortran -O2 -Wall z.f -c
z.f: In function ‘warn_character’:
z.f:3: warning: ‘c[1]{lb: 1 sz: 1}’ is used uninitialized in this function
Comment 9 Manuel López-Ibáñez 2008-08-18 16:53:42 UTC
To assess whether this is a middle-end issue, the alias dump (with VOPS and linenumbers) would be relevant.
Comment 10 Daniel Franke 2009-04-10 21:53:08 UTC
> To assess whether this is a middle-end issue, the alias dump (with VOPS 
> and linenumbers) would be relevant.

The testcase in #8 still gives the same warning.
Manuel, you refer to the output of -fdump-tree-alias or another one?
Comment 11 Dominique d'Humieres 2013-06-22 14:01:04 UTC
At revision 200321, I still get no warning for tests as in comment #7 and

pr13615_1.f90:3:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in this function [-Wuninitialized]

as in comment #8. What dump(s) would be necessary for any progress for this PR?
Comment 12 Manuel López-Ibáñez 2013-06-22 14:43:38 UTC
(In reply to Dominique d'Humieres from comment #11)
> At revision 200321, I still get no warning for tests as in comment #7 and
> 
> pr13615_1.f90:3:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in
> this function [-Wuninitialized]
> 
> as in comment #8. What dump(s) would be necessary for any progress for this
> PR?

The SSA built is:

warn_character (character(kind=1)D.24[1:1] & restrict dD.1877, integer(kind=4)D.8 _dD.1876)
{
  character(kind=1)D.24 cD.1878[1:1];
  character(kind=1)D.24 _2;

;;   basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;    prev block 0, next block 1, flags: (NEW, REACHABLE)
;;    pred:       ENTRY (FALLTHRU)
;;   starting at line 3
  [z.f : 3:0] # VUSE <.MEM_1(D)>
  _2 = [z.f : 3] cD.1878[1]{lb: 1 sz: 1};
  [z.f : 3:0] # .MEM_4 = VDEF <.MEM_1(D)>
  [z.f : 3] [z.f : 3] *d_3(D)[1]{lb: 1 sz: 1} = _2;
  # .MEM_5 = VDEF <.MEM_4>
  cD.1878 ={v} {CLOBBER};
  [z.f : 4:0] # VUSE <.MEM_5>
  return;
;;    succ:       EXIT

}

as you can see, the middle-end somehow thinks that the function reads from uninitialized memory. If this is the fault of gfortran or the middle-end, I really don't know. Perhaps Richard or Jakub have better idea of what is going on.
Comment 13 Mikael Morin 2013-08-25 13:58:12 UTC
gfortran outputs with the original testcase:

$ gfortran comment_0.f -O -Wall
comment_0.f: In function 'warn_integer':
comment_0.f:17:0: warning: 'a' is used uninitialized in this function [-Wuninitialized]
comment_0.f: In function 'warn_character':
comment_0.f:31:0: warning: 'c[1]{lb: 1 sz: 1}' is used uninitialized in this function [-Wuninitialized]

-Wall is necessary to trigger the warning, but now 'c' is correctly diagnosed as unitialized.  Closing as FIXED.