Re: gcc warning with "some variable may be used uninitialized in this function [-Wmaybe-uninitialized]" when building under msys

On 10/04/2018 01:00 PM, Simon Marchi wrote:
> On 2018-10-04 02:28, asmwarrior wrote:
>> Hi, when building gdb git head(which is
>> 875e539851bb2702f3292f819e220545a8776242 as 2018-10-04) under msys+gcc
>> 5.4, I see such warning:
>>
>>   CXX    infrun.o
>> In file included from ../../binutils-gdb/gdb/inferior.h:49:0,
>>                  from ../../binutils-gdb/gdb/infrun.c:26:
>> ../../binutils-gdb/gdb/progspace.h: In function 'void
>> handle_vfork_child_exec_or_exit(int)':
>> ../../binutils-gdb/gdb/progspace.h:285:47: warning: '*((void*)(&
>> maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace'
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>>    { set_current_program_space (m_saved_pspace); }
>>                                                ^
>> ../../binutils-gdb/gdb/infrun.c:931:6: note: '*((void*)(&
>> maybe_restore_inferior)+16).scoped_restore_current_program_space::m_saved_pspace'
>> was declared here
>>       maybe_restore_inferior;
>>       ^
>>   CXX    inline-frame.o
>>
>> Hope you devs can fix this. Thanks.
>>
>> Asmwarrior
> 
> I also see this from time to time.  I think it is a false positive, but I may be wrong.  Do you see a code path that could actually be problematic?

That warning is documented as producing false positives.
And those preexisting warnings are hard/ugly to disable
with #pragma GCC diagnostic push/pop.
That's why we disable -Werror for that warning.

There's been mild talking about moving -Wmaybe-uninitialized out
of -Wall in gcc, which I think would make sense.  Over time,
GCC's VRP etc. technology will improve and those same bugs
will be warned by -Wuninitialized instead (I'd hope).

See:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635

If the warnings confuse people too much, I'd be OK with
disabling -Wmaybe-uninitlized completely.  I left it as a
-Wno-error warning because even though it produces false positives,
it also helps catch bugs earlier in the compile-edit cycle,
when you're hacking some code, when you're introducing
uninitialized uses, and "make" ends up compiling just a few
files.

Thanks,
Pedro Alves