[Bug target/11052] [3.3 regression] [arm] ICE (segfault) compiling xfree86

["rearnsha@arm.com" <gcc-bugzilla@gcc.gnu.org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11052



------- Additional Comments From rearnsha@arm.com  2003-06-03 15:13 -------
Subject: Re:  [3.3 regression] [arm] ICE (segfault) 
 compiling xfree86


rearnsha@arm.com said:
> I need to look into this further, but it appears that REG_N_SETS
> hasn't  taken into account the auto_inc operation ;-( 

The key to this is that if-then-else conversion has dropped a REG_INC 
note.  Prior to conversion we had the following code paths

			+-----------+
			| cmp x, y  |
			+-----------+
			/           \
		+-----------+     +-----------+
		| t1 = 1    |     | t2 = 0    |
		| *++p = t1 |     | *++p = t2 |
		+-----------+     +-----------+
			\           /
			+-----------+
			|    ...    |
			+-----------+


If-then-else conversion is converting this to

		cmp x, y
		t3 = cond ? 1 : 0
		*++p = t3

In doing so it generates a new insn for the assignment, but fails to copy 
the REG_INC note.  Thus when mark_set_regs is called to update the reg 
life info it fails to note that p is updated.  This then causes p to be 
considered a constant and as a final consequence for p to be entirely 
eliminated (by reload) into a frame address.

This all starts to go wrong in noce_process_if_block.  It seems to me that 
there are three possibilities.

1) Don't allow this transformation if the insns have REG_INC notes (this 
is overkill, but safe).
2) Copy any REG_INC notes from *one* of the source insns.
3) Something else I've not thought of... :-)

Richard, any thoughts?

R.





------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.