On November 23, 2016 8:17:34 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote:
>On 11/23/2016 01:29 AM, Richard Biener wrote:
>> On Wed, Nov 23, 2016 at 1:12 AM, Serge Belyshev
>> <belys...@depni.sinp.msu.ru> wrote:
>>>> My builds for the last couple of days have all been failing in
>stage 2
>>>> like so:
>>>>
>>>> /home/arth/src/gcc/gcc/config/i386/i386.c: In function ‘rtx_def*
>ix86_expand_bui
>>>> ltin(tree, rtx, rtx, machine_mode, int)’:
>>>> /home/arth/src/gcc/gcc/config/i386/i386.c:38407:18: error: ‘fcn’
>may be used uni
>>>> nitialized in this function [-Werror=maybe-uninitialized]
>>>> emit_insn (fcn (target, accum, wide_reg, mem));
>>>> ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>
>>>> Anyone else seeing this?
>>>
>>> I'm seeing it too. The code is new, but the 'may be used
>unitialized'
>>> warning itself is, probably, an instance of the old PR36550.
>>>
>>> I have reduced this testcase to:
>>>
>>>
>//------------------------------------------------------------------------
>>> /* { dg-do compile } */
>>> /* { dg-options "-O2 -Wuninitialized" } */
>>>
>>> int force_reg (int, int);
>>> int expand_expr_real (int, int);
>>> void f (int);
>>>
>>> void ix86_expand_builtin (int fcode, int pmode)
>>> {
>>> int fcn;
>>> int i, addr, masked = 1;
>>>
>>> switch (fcode)
>>> {
>>> case 1:
>>> fcn = 1;
>>> masked = 0;
>>> goto s4fma_expand;
>>>
>>> case 2:
>>> fcn = 2;
>>> masked = 0;
>>> goto s4fma_expand;
>>>
>>> case 4:
>>> {
>>> s4fma_expand:
>>> for (i = 0; i < 4; i++)
>>> expand_expr_real (0, 0);
>>>
>>> addr = expand_expr_real (0, 0);
>>> force_reg ((pmode ? 0 : 2), addr);
>>>
>>> if (! masked)
>>> f (fcn);
>>> }
>>> }
>>> }
>>>
>//------------------------------------------------------------------------
>>>
>>> It fails with every gcc version down to 3.2 (the oldest one I could
>>> compile on my amd64 box). Note that this testcase is particularly
>>> flaky: recent gccs will not issue a warning if one, for example,
>changes
>>> the '2' to '1' in the force_reg() call.
>>
>> It's an interesting case where the uninit pass has to do sth else
>than
>> looking for a guard on the incoming path to the uninit PHI value
>> (there's none). But it has to simplify the guard on the use with
>> values on the edge of the uninit var:
>>
>> # fcn_1 = PHI <fcn_9(D)(3), 1(14), 2(4)>
>> # masked_3 = PHI <1(3), 0(14), 0(4)>
>> s4fma_expand:
>> ...
>> if (masked_3 == 0)
>> goto <bb 10>;
>> else
>> goto <bb 16>;
>>
>> <bb 16>:
>> goto <bb 11> (<L11>);
>>
>> <bb 10>:
>> f (fcn_1); [tail call]
>>
>> that's not something it even tries to do (and this case is
>particularly
>> simple even)
>But what left that in the IL? I'd expect jump threading to have
>optimized the masked_3 test away completely by isolating the paths
>where
>it's known to be zero from the path where it's known to be one.
I'm looking at another case where we fail to thread (albeit a lot more
complicated), it seems the backwards threader is not very good in handling
opportunities that require forward propagating of PHI args and DOM requires
excessive iteration (11 DOM passes in this other case...).
Richard.
>jeff
