On Wed, Nov 23, 2016 at 8:50 PM, Jeff Law <l...@redhat.com> wrote:
> On 11/23/2016 12:48 PM, Richard Biener wrote:
>>
>> 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...).
>
> Pass it along.
PR78496 was opened with the testcase.
Richard.
> I've got a case here which may need something similar. I've got some
> skeleton code that I might be able to beat into shape.
>
> Jeff
>
