Re: Bootstrap failure in stage 2 on i386.c

[Jeff Law <law at redhat dot com>]

On 11/23/2016 01:29 AM, Richard Biener wrote:
> On Wed, Nov 23, 2016 at 1:12 AM, Serge Belyshev
> <belyshev@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.

jeff