Bug 13031

What is really weird is that the insn is constant (and should be removed, at least does for the 
mainline because of a patch by me).

Created attachment 5128 [details]
preprocessed source

Andrew, would you mind elaborating on comment #1?  Are you suggesting that this
might already be solved in a cvs snapshot?

Most likely but I do not have the time to test it out.

I just built with -mcpu=ev4 -O0 and it worked fine, btw.  This is a suitable
workaround for me since I don't really care about the performance of the
gnome-libs-1.4.2 package.  I'll close the bug on the assumption that it's fixed
in a future gcc version.  Thanks!

Well, it's not fixed in the 3.3 branch, which will likely see another release,
so I reopen it. I can confirm this with 3.3.3 20031113,  but does not occur
with 3.3.2 release.

Reverting the patch for PR 12654 (which seemed like a possible culprit) does
not help.

Test case:

void emit(int, int);
int f(void);
static int signals[5];

static inline void select(int sel, void *klass)
{
  emit(klass ? 0 : f(), signals[sel ? 0 : 1]);
}

void all(void *gil, void *l, void *icon)
{
  while (l)
    if (icon)
      select(0, gil);
}

23.lreg creates this RTL:

(eq (const_int 0 [0x0])
    (const_int 0 [0x0])

which the Alpha machine description cannot handle. Andrew, is it possible to
backport your patch? Otherwise, one could kludge the machine description
to emit whatever for it, but maybe other mds also don't lilke this.

No it will not work as it works with GCSE to eliminate them since the pattern does not exist until 
lreg the patch will not work, sorry, I though it existed earlier (maybe it does).

Falk, are you sure it doesn't ICE with GCC 3.3.2 release? I don't see any
relevant patches between 10/16 and 10/22.

Seems I've confused something. It ICEs with 3.3.2, today's 3.3.3, but not 3.2.3.
Sorry.

Andrew, it's really a GCSE deficiency: the BB in which (reg 72) is compared is
dominated by the BB in which it is set to 0, so GCSE should be able to propagate
the constant and turn the conditional jump into an unconditional one.

What is the patch you're talking about?

Actually the problem is even worse, the problem is that there are subregs and 
sign_extend which confuss GCSE in 3.3 so my patch:
"Consider a COMPARE of the same registers is a constant if they are not floating point 
registers." does not work at all for this case. Another patch must have fixed the deficiency 
in GCSE.

The problem is also present on mainline (i.e local-alloc creates the same
pattern) but for some reason it doesn't ICE there.

Eric, I do not see that RTL being created by local-alloc (Are you sure that you are not looking at an 
older RTL dump?).

Sorry Andrew, I messed it up.  You're right, GCSE correctly does its job on
mainline:

CONST-PROP: Replacing reg 72 in jump_insn 36 with constant (const_int 0 [0x0])
Purged non-fallthru edges from bb 5
GLOBAL CONST-PROP: Replacing reg 72 in insn 36 with constant (const_int 0 [0x0])

That's good news!

The regression in PR 13031 was introduced or exposed by this patch:

2002-06-10  Roger Sayle  <roger@eyesopen.com>

        * toplev.c (rest_of_compilation): Disable early if-conversion pass.
        * gcse.c (bypass_conditional_jumps): Fix typo in setcc test.

The test case starts passing on mainline with this patch:

2003-02-08  Zdenek Dvorak  <rakdver@atrey.karlin.mff.cuni.cz>

        * cfgloop.h (fix_loop_placement, can_duplicate_loop_p,
        duplicate_loop_to_header_edge, loopify, remove_path, split_loop_bb):
        Declare.
        (DLTHE_FLAG_UPDATE_FREQ): New.
        * cfgloopmanip.c
        [lots more]

The hunts took place with mainline sources on i686-pc-linux-gnu with a
cross cc1 for alphaev67-unknown-linux, using the test case in comment
#6 compiled with -O3.

I'm currently bootstrapping and regression testing a GCSE patch for
this PR.  This improves cprop_jump_insn, which works around the real
problem in local reg-alloc.  Given where we are with gcc 3.3.3, I'd
rather a work around that I understand, than even look at reload!

Patch in progress from Roger.

Subject: Bug 13031

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	sayle@gcc.gnu.org	2003-12-20 19:59:56

Modified files:
	gcc            : ChangeLog gcse.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/compile: 20031220-1.c 

Log message:
	PR optimization/13031
	* gcse.c (cprop_jump): Backport code clean-up and bug-fix
	from mainline [2003-05-20 Sayle, Hirata and Rennecke patch].
	(cprop_insn): Don't attemp further substitutions if the
	current instruction has been deleted.
	(local_cprop_pass): Likewise.
	
	* gcc.c-torture/compile/20031220-1.c: New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.850&r2=1.16114.2.851
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcse.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.223.2.8&r2=1.223.2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.2261.2.339&r2=1.2261.2.340
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20031220-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=NONE&r2=1.1.2.1

Subject: Bug 13031

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	sayle@gcc.gnu.org	2003-12-20 20:17:54

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.c-torture/compile: 20031220-1.c 

Log message:
	2003-12-20  Roger Sayle  <roger@eyesopen.com>
	
	PR optimization/13031
	* gcc.c-torture/compile/20031220-1.c: New test case.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3291&r2=1.3292
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20031220-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2

Fixed.