Bug 40206 - [gfortran] Incorrect warning with -Wuninitialized
Summary: [gfortran] Incorrect warning with -Wuninitialized
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2009-05-20 12:25 UTC by Martin Reinecke
Modified: 2010-07-15 15:09 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.5.0
Last reconfirmed: 2009-05-20 12:43:26


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Reinecke 2009-05-20 12:25:34 UTC
gfortran from the current trunk gives a warning for the code below:

module fitsmod2
implicit none

contains

function char2type (char)
  character, intent(in) :: char
  integer :: char2type

  select case (char)
    case ('E','e')
      char2type=1
    case default
      char2type=-1234
  end select
end function

function fixkey (input)
  character(len=*), intent(in) :: input
  character(len=1024) fixkey

  fixkey=input
end function

end module fitsmod2

/scratch/blah5/planck/LevelS/bugrep>gfortran -v -Wuninitialized -c -O fitsmod2.f90
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure --prefix=/afs/mpa/data/martin/ugcc --with-mpfr-include=/usr/include --with-mpfr-lib=/usr/lib --with-gmp-include=/usr/include --with-gmp-lib=/usr/lib --enable-languages=c++,fortran --enable-checking=release
Thread model: posix
gcc version 4.5.0 20090520 (experimental) [trunk revision 147731] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-Wuninitialized' '-c' '-O' '-mtune=generic'
 /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/f951 fitsmod2.f90 -quiet -dumpbase fitsmod2.f90 -mtune=generic -auxbase fitsmod2 -O -Wuninitialized -version -fintrinsic-modules-path /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/finclude -o /tmp/ccPgtd3C.s
GNU Fortran (GCC) version 4.5.0 20090520 (experimental) [trunk revision 147731] (i686-pc-linux-gnu)
        compiled by GNU C version 4.5.0 20090520 (experimental) [trunk revision 147731], GMP version 4.2.1, MPFR version 2.3.2
warning: GMP header version 4.2.1 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.5.0 20090520 (experimental) [trunk revision 147731] (i686-pc-linux-gnu)
        compiled by GNU C version 4.5.0 20090520 (experimental) [trunk revision 147731], GMP version 4.2.1, MPFR version 2.3.2
warning: GMP header version 4.2.1 differs from library version 4.2.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
fitsmod2.f90: In function 'char2type':
fitsmod2.f90:23: warning: '__result_char2type' may be used uninitialized in this function
fitsmod2.f90:23: note: '__result_char2type' was declared here
COLLECT_GCC_OPTIONS='-v' '-Wuninitialized' '-c' '-O' '-mtune=generic'
 as -V -Qy -o fitsmod2.o /tmp/ccPgtd3C.s
GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.18
COMPILER_PATH=/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/:/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-Wuninitialized' '-c' '-O' '-mtune=generic'

Several things are odd about this warning:
- the line number in question is not inside the function "char2type"
- the warning is given for a variable that is not defined by the user
- the result of "char2type" is actually initialised in all code paths
Comment 1 Tobias Burnus 2009-05-20 12:43:26 UTC
The dump is the following. gfortran_select_string returns only 0, 1, or 2, but the middle end does not know this.

Manuel, do you have an idea how to solve this?

    case_num.1 = _gfortran_select_string ((void *) &jumptable.0, 3, char, 1);
    switch (case_num.1)
      {
        case 1 ... 1:;
        case 2 ... 2:;
        __result_char2type = 1;
        goto L.1;
        case 0 ... 0:;
        __result_char2type = -1234;
        goto L.1;
      }
Comment 2 Daniel Franke 2009-05-20 12:48:58 UTC
I'd suspect this to be a related to Jakub's recent changes applied for PR39666 (i.e. r147136)? Does your testcase work for r147135?
Comment 3 Martin Reinecke 2009-05-20 13:03:45 UTC
(In reply to comment #2)
> I'd suspect this to be a related to Jakub's recent changes applied for PR39666
> (i.e. r147136)? Does your testcase work for r147135?

I cannot check this quickly. However I tried with gfortran 4.2.3 and the head of the 4.4 branch and got similar warnings. Surprisingly, these compilers warn about
line 22 (instead of 23), which is still wrong...

Comment 4 Manuel López-Ibáñez 2009-05-20 13:12:52 UTC
(In reply to comment #2)
> I'd suspect this to be a related to Jakub's recent changes applied for PR39666
> (i.e. r147136)? Does your testcase work for r147135?
> 

On the contrary, I think this is a missed testcase from Jakub's changes, because the default label is added during gimplification. Perhaps the patch of Jakub can be extended to handle this, or the fortran FE can add the default label in the correct place.

In addition, why gfortran does not name the variable char2type? Can you access that variable when debugging?
Comment 5 Tobias Burnus 2009-05-20 13:40:58 UTC
    switch (case_num.1)
      {
        case 1 ... 1:;
        case 2 ... 2:;
        __result_char2type = 1;
        goto L.1;
        case 0 ... 0:;
        __result_char2type = -1234;
        goto L.1;
      }

Wouldn't this solved by adding a "default:" as C does for "default:" ?

> In addition, why gfortran does not name the variable char2type?

Good question. it clashes with the name of the function, but I don't know whether that is a problem or not. In any case: you are right, it makes debugging harder ...
Comment 6 Richard Biener 2009-05-20 14:14:03 UTC
The FE should use a default label for the last case in the switch stmt.
I also think the FE does premature optimization here, but ...
Comment 7 Jakub Jelinek 2009-05-20 14:32:03 UTC
For all involved strings being non-array CHAR with length 1 I fail to see why normal SWITCH_EXPR isn't used instead (though that would just be an optimization).

The middle-end can't know the _gfortran_select_string function will never return numbers bigger than the size of the jump table it is called with, so the Fortran FE should help it.  If the table contains a default label, it should use a default: case label instead of corresponding number, and if there is no case label, but all possible strings are covered, it can pick a random case label as the default.
Comment 8 Jakub Jelinek 2010-07-15 07:53:09 UTC
Subject: Bug 40206

Author: jakub
Date: Thu Jul 15 07:52:51 2010
New Revision: 162209

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162209
Log:
	PR fortran/40206
	* trans-stmt.c (gfc_trans_character_select): Always use NULL for high
	in CASE_LABEL_EXPR and use NULL for low for the default case.

	* gfortran.dg/select_char_3.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/select_char_3.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

Comment 9 Jakub Jelinek 2010-07-15 15:09:43 UTC
Should be fixed now for 4.6+.