Different Test Results w/ -march=pentiumpro

Different Test Results w/ -march=pentiumpro

[acs]

On my UnixWare 2.1.2 (i386-pc-sysv4.2uw2.1.2) system with the 0502 snapshot,
I get different test results when I add -march=pentiumpro to BOOT_CFLAGS.

In the first case I built with:
BOOT_CFLAGS='-O3 -malign-jumps=4 -malign-loops=4 -malign-functions=4'

while in the second, I added -march=pentiumpro:
BOOT_CFLAGS='-O3 -march=pentiumpro -malign-jumps=4 -malign-loops=4 -malign-functions=4'


Here are the diffs in the summaries:

diff ~/tmp/egcs-19980502.results egcs-19980502.results-ppro
43a44,48
> FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 
> FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -fomit-frame-pointer -finline-functions 
> FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
> FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
> FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -g 
47,48c52,53
< # of expected passes          6043
< # of unexpected failures      1
---
> # of expected passes          6038
> # of unexpected failures      6


Let me know if there's some more information that would be helpful.

vin shelton

Re: Different Test Results w/ -march=pentiumpro

[H.J. Lu]

> 
> On my UnixWare 2.1.2 (i386-pc-sysv4.2uw2.1.2) system with the 0502 snapshot,
> I get different test results when I add -march=pentiumpro to BOOT_CFLAGS.
> 
> In the first case I built with:
> BOOT_CFLAGS='-O3 -malign-jumps=4 -malign-loops=4 -malign-functions=4'
> 
> while in the second, I added -march=pentiumpro:
> BOOT_CFLAGS='-O3 -march=pentiumpro -malign-jumps=4 -malign-loops=4 -malign-functions=4'
> 
> 

I am not sure if this patch works or not. Should egcs 1.0.x also be
fixed?

H.J.
--
Thu May  7 16:48:52 1998  H.J. Lu  (hjl@gnu.org)

	* final.c (final_scan_insn): Don't ignore the test/compare
	insn if there may be an overflow.

Index: final.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/final.c,v
retrieving revision 1.1.1.27
diff -u -p -r1.1.1.27 final.c
--- final.c	1998/05/07 15:45:19	1.1.1.27
+++ final.c	1998/05/07 23:46:41
@@ -297,7 +297,7 @@ static void leaf_renumber_regs	PROTO((rt
 static int alter_cond		PROTO((rtx));
 #endif
 
-extern char *getpwd ();
+extern char *getpwd		PROTO((void));
 \f
 /* Initialize data in final at the beginning of a compilation.  */
 
@@ -2507,10 +2507,11 @@ final_scan_insn (insn, file, optimize, p
 		      XEXP (SET_SRC (set), 1)
 			= alter_subreg (XEXP (SET_SRC (set), 1));
 		  }
-		if ((cc_status.value1 != 0
-		     && rtx_equal_p (SET_SRC (set), cc_status.value1))
-		    || (cc_status.value2 != 0
-			&& rtx_equal_p (SET_SRC (set), cc_status.value2)))
+		if ((cc_status.flags & CC_NO_OVERFLOW) == 0
+		    && ((cc_status.value1 != 0
+			 && rtx_equal_p (SET_SRC (set), cc_status.value1))
+			|| (cc_status.value2 != 0
+			    && rtx_equal_p (SET_SRC (set), cc_status.value2))))
 		  {
 		    /* Don't delete insn if it has an addressing side-effect.  */
 		    if (! FIND_REG_INC_NOTE (insn, 0)

Re: Different Test Results w/ -march=pentiumpro

[Jim Wilson]

The -march=pentiumpro option is known to have problems, because of bugs in
the conditional move instructions.

I just installed a patch to disable the conditional move support, so this
problem may be gone now.

Jim

Re: Different Test Results w/ -march=pentiumpro

[H.J. Lu]

> 
> The -march=pentiumpro option is known to have problems, because of bugs in
> the conditional move instructions.
> 

Is this an integer conditional move bug? The fp conditional move has
been disabled for a while now. I thought the bug was in final_scan_insn
and was cpu independent. It looks like I was wrong again :-(.


-- 
H.J. Lu (hjl@gnu.org)

Re: Different Test Results w/ -march=pentiumpro

[Jim Wilson]

	Is this an integer conditional move bug? The fp conditional move has
	been disabled for a while now.

yes.  The integer conditional moves have essentially the same bug that caused
the fp conditional moves to be disabled.

Jim

Re: Different Test Results w/ -march=pentiumpro

[H.J. Lu]

> 
> On my UnixWare 2.1.2 (i386-pc-sysv4.2uw2.1.2) system with the 0502 snapshot,
> I get different test results when I add -march=pentiumpro to BOOT_CFLAGS.
> 
> In the first case I built with:
> BOOT_CFLAGS='-O3 -malign-jumps=4 -malign-loops=4 -malign-functions=4'
> 
> while in the second, I added -march=pentiumpro:
> BOOT_CFLAGS='-O3 -march=pentiumpro -malign-jumps=4 -malign-loops=4 -malign-functions=4'
> 
> 
> Here are the diffs in the summaries:
> 
> diff ~/tmp/egcs-19980502.results egcs-19980502.results-ppro
> 43a44,48
> > FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 
> > FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -fomit-frame-pointer -finline-functions 
> > FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
> > FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
> > FAIL: gcc.c-torture/execute/loop-4.c execution,  -O2 -g 

There is a bug between final_scan_insn () and notice_update_cc () on
x86. final_scan_insn () may optimize out a test/compare instruction
when egcs thinks the condition code is already set up as desired.
The problem is notice_update_cc on x86 will update the condition code
for all kinds of instructions, including

	subl   %ecx,%eax

For

	subl   %ecx,%eax
	movl   %eax,0xffffffd4(%ebp)
	testl  %eax,%eax

when egcs sees "testl  %eax,%eax", it knows the condition code
is changed by "subl   %ecx,%eax" and "testl  %eax,%eax" is ignored.

Now we get a problem. Since "subl   %ecx,%eax" may cause overflow,
the condition code will be bogus in this case. Because of this,
check_dbra_loop () is miscompiled for PPro.

One way to fix it is to disable the condition code optimization. Or
we can add a bit to cc_status.flags, CC_UPDATED_BY_TEST_COMPARE.
We set the CC_UPDATED_BY_TEST_COMPARE bit in NOTICE_UPDATE_CC and
final_scan_insn () check the CC_UPDATED_BY_TEST_COMPARE bit before
optimizing out the condition code.

BTW, this bug may be cpu independent and may exist in egcs 1.0.x. We 
just happen to see egcs itself be miscompiled this time.


H.J.