http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644



Matt Hargett <matt at use dot net> changed:



           What    |Removed                     |Added

----------------------------------------------------------------------------

            Summary|bootstrap-lto fails on      |maybe-uninitialized false

                   |current trunk (with and     |positive

                   |without profiledbootstrap)  |



--- Comment #11 from Matt Hargett <matt at use dot net> 2013-03-01 23:34:53 UTC 
---

The current false positives emitted:



mhargett@chert:/work/mhargett/gcc-trunk-lto-O3-debug/gcc$

/work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -O3 -g -flto=jobserver -flto-partition=none -frandom-seed=1 -gtoggle -DIN_GCC

  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall

-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic

-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common

 -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov-dump.o                

libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov-dump

../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

              ^

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared

here

   struct backtrace_view ehdr_view;

                         ^

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be

used uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

              ^

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared

here

   struct backtrace_view ehdr_view;

                         ^

../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   memcpy (&ehdr, ehdr_view.data, sizeof ehdr);

          ^

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.data' was declared

here

   struct backtrace_view ehdr_view;

                         ^





which is a false positive, because



ehdr_view's fields are correctly initialized via a call from elf_add() to

backtrace_get_view()

  view->data = (char *) map + inpage;

  view->base = map;

  view->len = size;



if the mmap() earlier in the backtrace_get_view() didn't fail, view is

initialized and the backtrace_get_view() returns 1. if that mmap() fails, view

remains uninitialized and backtrace_get_view() returns 0.



elf_add()'s invocation checks the return value of backtrace_get_view(). in the

0 (failure) case, backtrace_release_view() is never invoked:

  if (!backtrace_get_view (state, descriptor, 0, sizeof ehdr, error_callback,

                           data, &ehdr_view))

    goto fail;



since backtrace_release_view() is never called in the case where the fields are

uninitialized, the warning is a false positive. while it occurs here with the

confluence of several optimizations, it looks like the same problem would

happen in a contrived single-file case.



attached are the temp files for the module the generated this false positive.

Reply via email to