On 9/2/16, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote:
> On 02/09/16 20:27, Segher Boessenkool wrote:
>> On Fri, Sep 02, 2016 at 02:21:07PM -0400, Eric Gallager wrote:
>>> ../../gcc/combine.c: In function ‘int combine_instructions(rtx_insn*,
>>> unsigned int)’:
>>> ../../gcc/combine.c:1310:8: warning: ‘prev’ may be used uninitialized
>>> in this function [-Wmaybe-uninitialized]
>>> if ((next = try_combine (insn, prev, NULL, NULL,
>>> ^~
>>
>> That is:
>>
>> if (HAVE_cc0
>> && JUMP_P (insn)
>> && (prev = prev_nonnote_insn (insn)) != 0
>> && NONJUMP_INSN_P (prev)
>> && sets_cc0_p (PATTERN (prev)))
>> {
>> if ((next = try_combine (insn, prev, NULL, NULL,
>> &new_direct_jump_p,
>> last_combined_insn)) != 0)
>>
>> so prev is always initialised here. Could you try to find out why GCC
>> warns anyway? Or open a PR?
>>
>> HAVE_cc0 probably expands to 0 (I'm not sure what your target is), that
>> might have something to do with it.
>
> Unfortunately, the location reported by GCC is sometimes wrong, because
> location tracking in the middle-end is far from perfect.
> https://gcc.gnu.org/PR40635 https://gcc.gnu.org/PR53917
>
> The only way to know for sure what GCC is warning about is to look at the
> uninit dump.
How exactly do I generate an uninit dump? I'm not seeing any relevant
options in the GCC manual...
>
> Moreover, if the warning is bogus and not a regression, it is very likely
> that it is reported already here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
>
> The effort dedicated to report and analyze the report would be better spent
> fixing any of the issues already known.
>
> Nevertheless, assignments within 'if' are one of the things that make
> reading GCC code harder than it needs to be (and combine.c is scary).
So would a patch to move the assignment out of the 'if' be better then?
(Also, what about the one in varasm.c?)
