This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bootstrap failure in stage 2 on i386.c

On 11/23/2016 01:29 AM, Richard Biener wrote:
On Wed, Nov 23, 2016 at 1:12 AM, Serge Belyshev
<> 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:
        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)>
  if (masked_3 == 0)
    goto <bb 10>;
    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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]