This is the mail archive of the gcc@gcc.gnu.org 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]

Re: a regression on 2.95.3 (was Re: How can I submit a large testresult?)


Hi Bernd,

The regressions caused by fixing another regression on
h8300-hms-gcc-2.95.3.test4 are

+FAIL: gcc.c-torture/execute/loop-7.c execution,  -O3 -fomit-frame-pointer -funroll-loops
+FAIL: gcc.c-torture/execute/loop-7.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions

I think this is OK.  After investigating the resulting assembly code,
I found that it was "luckily" wrong on the unpatched gcc-2.95.3.test4,
which is why this was not causing a failure.  That is, a bug covered
another bug.  main() of the loop7.c is as follows.

_main:
	sub.l er2,er2   ; clear er2
	subs #1,er2     ; load -1 to er2
	mov.l	er2,er2 ; test er2 (added by my patch, see below)
	bge	.L20    ; branch if nonnegative
	jsr	@_abort ; negative, so abort
.L20:
	sub.l	er0,er0 ; nonnegative, so exit
	jsr	@_exit
	.end

No wonder the above aborts.  The only difference between the unpatched
gcc-2.95.3.test4 and the patched version (see below) is that the test
insn "mov.l er2, er2" is newly added because the previous insn does
not set cc0 appropriately, which my patch addresses.  Thus it's
probably a bug somewhere in the loop unroller or function inliner.
Since loop-7.c fails even on i386, I think this is a global problem.
So please consider the patch posted in

http://gcc.gnu.org/ml/gcc/2001-02/msg01065.html

A ChangeLog entry was missing, so here it is.

2001-02-22  Kazu Hirata  <kazu@hxi.com>

	* config/h8300/h8300.md (movsi_h8300hs): Split the 2nd alternative
	into two parts.

I'll post this for gcc-3.0 and gcc-3.1 as well to see if I can get an
approval.

Thanks,

Kazu Hirata


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