Re: Bootstrap problem on i386 when configured with CFLAGS=-O in environment

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <200002040140.TAA66034@latour.rsch.comm.mot.com>, I wrote:

> Gerald Pfeifer found a problem where recent snapshots would fail
> during stage 2 of the bootstrap on FreeBSD/i386 when CFLAGS=-O (He
> also noted that he could not reproduce the problem on any other
> platform he tried.  Of particular note, I later determined that the
> failure does *not* occur on Linux/i386).

I have produced a small test case and pin-pointed the bad code in gcc
and, more importantly, I can now explain how to generate the failure
on Linux/i386 as well.  At least on my identical hardware platforms,
by default, Linux is configuring for PROCESSOR_PENTIUMPRO and FreeBSD
for PROCESSOR_I386.  In particular, this affects the expansion of
TARGET_PARTIAL_REG_STALL and (perhaps) TARGET_PROMOTE_QImode.

[Details of how cc1 is currently miscompiled with CFLAGS=-O in stage2 removed.]

Here is a distilled test case:

int foo (void);

int
main (void)
{
  int bar = foo ();

  if (bar & 0x8001)
    return 1;
  return 0;
}

int foo (void) { return 0x11000; }

With recent gcc snapshots on FreeBSD/i386 and Linux/i386, main()
correctly returns 0 when compiled with -O2 or -O0, but 1 when compiled
with -O -m386.

The problem is that split_insns() generates and try_split() accepts
this:

(set (reg:CCNO 17 flags)
    (compare:CCNO (and:SI (reg:SI 0 eax)
            (const_int -32767 [0xffff8001]))
        (const_int 0 [0x0])))

as a valid replacement for this:

(set (reg:CCNO 17 flags)
    (compare:CCNO (and:HI (reg:HI 0 ax)
            (const_int -32767 [0xffff8001]))
        (const_int 0 [0x0])))

[Sorry, but I need to refer to the code in the generated file,
insn-recog.c - I don't yet know how to debug past this point.]

22982     x2 = XEXP (x1, 1);
22983     if (GET_CODE (x2) == CONST_INT
22984         && XWINT (x2, 0) == 0
22985         && (! TARGET_PARTIAL_REG_STALL && reload_completed
22986      && (GET_MODE (operands[0]) == HImode
22987          || (GET_MODE (operands[0]) == QImode 
22988              && (TARGET_PROMOTE_QImode || optimize_size)))))
22989       {
22990         return gen_split_551 (operands);
22991       }
22992     x1 = XEXP (x0, 0);
22993     goto L883;

Either this code is bad whenever ix86_cpu != PROCESSOR_PENTIUMPRO or
the generated split is bad (as shown above).

Much thanks from me and Gerald to anyone that can debug this problem
from this point to a fix.

Regards,
Loren