User account creation filtered due to spam.

Bug 32035 - '<anonymous>' may be used uninitialized in this function
Summary: '<anonymous>' may be used uninitialized in this function
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 minor
Target Milestone: ---
Assignee: Francois-Xavier Coudert
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords: diagnostic, missed-optimization, patch
Depends on:
Blocks: 32720
  Show dependency treegraph
 
Reported: 2007-05-22 10:09 UTC by Philippe Schaffnit
Modified: 2007-07-27 14:28 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-07-04 07:34:44


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Schaffnit 2007-05-22 10:09:29 UTC
Hi!

This a very minor thing, but it turns out to be a bit annoying: gfortran now and then (rather randomly in my opinion) throws this compilation diagnostic, of which I don't seem to make head or tail:
warning: '<anonymous>' may be used uninitialized in this function

This warning looks quite meaningless to me (at best).

Cheers!

Philippe

PS: gfortran -O1 -g -Wall -c Source.f90
Source.f90: In function 'test':
Source.f90:35: warning: '<anonymous>' may be used uninitialized in this function

PPS: don't look for much sense, I just tried to cut down some valid sources while keeping this behaviour...

!
      SUBROUTINE Test
!
      IMPLICIT   NONE
!
      LOGICAL ::   Logical_1
!
      INTEGER :: Integer_1
      INTEGER :: Integer_2
      INTEGER :: Integer_3
      INTEGER :: Integer_4
      INTEGER, PARAMETER :: Dft = 4
      INTEGER, PARAMETER :: Parameter_1 = 1, Parameter_2 = 2
!
      CHARACTER ( LEN = 30 ) ::   String_1
!
      READ ( 5, * ) String_1
!
      Integer_3  = Parameter_1
      Integer_4 = 666
!
      SELECT CASE ( TRIM(String_1) )
      CASE ( "A" )
        Integer_3  = Parameter_1
      CASE ( "B" )
        Integer_3  = Parameter_2
      CASE DEFAULT
        STOP
      END SELECT
!
      IF ( Integer_3 .EQ. Parameter_2 ) THEN
!
        READ ( 5, * ) Integer_1
!
        Integer_2 = 0
        DO Integer_4 = 1, Integer_1
!
          READ ( 5, * ) String_1
          SELECT CASE ( TRIM(String_1) )
          CASE ( "C" )
            Logical_1 = .TRUE.
          CASE ( "D" )
            Logical_1 = .FALSE.
          CASE DEFAULT
            STOP
          END SELECT
!
        ENDDO
      ENDIF
!
      RETURN
      END SUBROUTINE Test
!


PPPS:
gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /USER/philippe/Irix/Gcc_Sources/configure --prefix=/usr1/MICRESS/Philippe/Tools/Gcc --enable-languages=c,fortran --disable-maintainer-mode --disable-shared --with-mpfr=/usr1/MICRESS/Philippe/Tools/Mpfr --with-gmp=/usr1/MICRESS/Philippe/Tools/Gmp --with-htmldir
Thread model: posix
gcc version 4.3.0 20070522 (experimental)
Comment 1 Tobias Burnus 2007-05-22 11:15:35 UTC
The error message comes from the middle-end and the variable name is Integer_1, line 33 is:

        READ ( 5, * ) Integer_1

There are two problems: First, why has the variable no name for the middle end; secondly, why does the middle end print this warning for the following call:

        _gfortran_st_read (&dt_parm.5);
        _gfortran_transfer_integer (&dt_parm.5, &integer_1, 4);
        _gfortran_st_read_done (&dt_parm.5);
Comment 2 Andrew Pinski 2007-05-22 16:31:00 UTC
> why has the variable no name for the middle end;
that is a front issue for now, it might not be complaining about Integer_1 but a different variable.
Comment 3 Tobias Burnus 2007-05-22 18:29:14 UTC
> > why has the variable no name for the middle end;
> that is a front issue for now

Hmm, why did this trick to get rid of PRs not work? ;-)

Reduced test case:

      subroutine Test
      implicit none
      integer,volatile :: Integer_1
      integer          :: Integer_4
      character(len=3) :: String_1
      String_1 = '124'
      select case(String_1)
        case default
          stop
      end select
      Integer_1 = 3
      do Integer_4 = 1, Integer_1
        String_1 = '098'
        select case(String_1)
          case default
            stop
        end select
      end do
      end subroutine Test

Gives two bogus warnings:
  warning: 'integer_4' may be used uninitialized in this function
  warning: '<anonymous>' may be used uninitialized in this function

The integer_4 warning is completely surprising:
  int4 integer_4;
[...]
    integer_4 = 1;
    if (integer_4 <= D.1366)
[...]
              D.1373 = integer_4 == D.1366;
              integer_4 = integer_4 + 1;
I fail to see why it could be seen as undefined.

For <anonymous> I don't see what goes wrong.
Comment 4 Andrew Pinski 2007-05-22 18:32:18 UTC
It might have to do with stop not being marked as noreturn.
Comment 5 Tobias Burnus 2007-05-22 20:14:46 UTC
> It might have to do with stop not being marked as noreturn.
How to mark as noreturn? I mean differently from what is alreay done in trans-decl.c:

  gfor_fndecl_stop_numeric =
    gfc_build_library_function_decl (get_identifier (PREFIX("stop_numeric")),
                                     void_type_node, 1, gfc_int4_type_node);
  /* Stop doesn't return.  */
  TREE_THIS_VOLATILE (gfor_fndecl_stop_numeric) = 1;
Comment 6 Andrew Pinski 2007-05-23 03:18:26 UTC
Ok, what is going on here has to deal with how select/case works for strings.   What the front-end produces confuses the crazy out of the middle-end and the middle-end does not know where the jumps can go so it assumes it can go to either place.  After the first select, the middle thinks it can reach where the second select is supposed to reach.  So what should happen here is the front-end respentation of select/case for strings need to be improved.  

Maybe instead of using labels, it can use a constant value and then a normal switch statement.  This will also improve code gen and less confuse the middle-end.
Comment 7 Steven Bosscher 2007-07-11 21:42:08 UTC
The proposed patch (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01098.html) breaks library compatibility. Is this intentional?
Comment 8 Francois-Xavier Coudert 2007-07-11 21:54:24 UTC
I think it was decided that until 4.3 is released, we don't care about libgfortran ABI stability (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00927.html)
Comment 9 Francois-Xavier Coudert 2007-07-27 14:26:54 UTC
Subject: Bug 32035

Author: fxcoudert
Date: Fri Jul 27 14:26:43 2007
New Revision: 126978

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126978
Log:
	PR fortran/32035

	* trans-stmt.c (gfc_trans_character_select): Replace the
	mechanism with labels by a SWITCH_EXPR.
	* trans-decl.c (gfc_build_builtin_function_decls): Change
	return type for select_string.

	* runtime/select.c (select_string): Adjust prototype and function
	so that the return value is an integer, not a pointer.

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

Added:
    trunk/gcc/testsuite/gfortran.dg/select_char_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/runtime/select.c

Comment 10 Francois-Xavier Coudert 2007-07-27 14:28:46 UTC
Fixed on mainline.