Current gfortran (mainline and 4.1 branch) appears to get quite confused when compiling the following code with -O -Wuninitialized: module foo implicit none type bar integer :: yr integer :: mth integer :: day end type contains function baz(arg) result(res) type(bar), intent(in) :: arg type(bar) :: res logical, external:: some_func if (.not. some_func(arg)) then call fatal('arg not valid') else res = arg end if end function baz end module foo ~/tmp>gfortran -v -c -Wuninitialized -O bugtest.f90 Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,fortran --with-gmp=/usr/local/appl/gmp-4.1.4 --enable-checking=release Thread model: posix gcc version 4.2.0 20060123 (experimental) /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.2.0/f951 bugtest.f90 -quiet -dumpbase bugtest.f90 -mtune=generic -auxbase bugtest -O -Wuninitialized -version -o /tmp/cchtyroB.s GNU F95 version 4.2.0 20060123 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0 20060123 (experimental). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 'res.daybugtest.f90: In function 'baz': bugtest.f90:12: warning: ' may be used uninitialized in this function 'res.mthbugtest.f90:12: warning: ' may be used uninitialized in this function 'res.yrbugtest.f90:12: warning: ' may be used uninitialized in this function as -V -Qy -o bugtest.o /tmp/cchtyroB.s GNU assembler version 2.15 (i686-pc-linux-gnu) using BFD version 2.15 The 4.0 branch produces ~/tmp>gfortran -c -Wall -O bugtest.f90 bugtest.f90: In function 'baz': bugtest.f90:12: warning: 'res .day ' may be used uninitialized in this function bugtest.f90:12: warning: 'res .mth ' may be used uninitialized in this function bugtest.f90:12: warning: 'res .yr ' may be used uninitialized in this function which looks better, but not quite right either.
Confirmed.
Is it possible to fix this before gcc 4.2? Whenever I see these garbled warnings I have a very bad feeling that something completely unintended is happening inside the compiler, and I guess that many users could feel the same way.
To me this sounds more like a middle-end issue. The ME apparently doesn't have means to use language specific diagnosics hooks. Also see comment #2 for PR24784 at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24784#c2
Subject: Bug number PR diagnostic/25923 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-04/msg01388.html
Subject: Bug 25923 Author: simartin Date: Tue Apr 24 21:52:16 2007 New Revision: 124121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124121 Log: 2007-04-24 Simon Martin <simartin@users.sourceforge.net> PR diagnostic/25923 * tree-pass.h (TDF_DIAGNOSTIC): New dump control to specify that a diagnostic message is being built. * tree-pretty-print.c (dump_generic_node): Only write the formatted text into BUFFER's stream if we are not building a diagnostic message. * toplev.c (default_tree_printer): Pass TDF_DIAGNOSTIC to dump_generic_node. * Makefile.in (toplev.o): Depend on tree-pass.h. Added: trunk/gcc/testsuite/gfortran.dg/pr25923.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/gcc/tree-pass.h trunk/gcc/tree-pretty-print.c
I confirm that this is fixed for me on mainline. Is the patch non-invasive enough for a backport to 4.2 (possibly after the 4.2.0 release)?
Fixed in trunk. Not a regression, no backport. Closing.