vax optimization breakage?

[Brandon Creighton <bjc at pobox dot com>]

Hello.  

The following test code is compiled incorrectly by gcc (both in-tree
gcc and recent snapshots) at -O2.  Details follow.  I have observed 
this behavior with the following configurations:
(i386-unknown-openbsd2.7 x vax-unknown-openbsd2.7)
(i386-unknown-openbsd2.7 x vax-unknown-ultrix)
vax-unknown-openbsd2.7 (native)
(i686-pc-linux-gnu x vax-unknown-openbsd2.7)


int cnt;
void
func()
{
	int i;

	cnt = 0;
	for (i = 0; i<5; i++) {
		cnt++;
	}
}


The code that is generated looks like this:

#NO_APP
gcc2_compiled.:
___gnu_compiled_c:
.text
        .align 1
.globl _func
        .type   _func , @function
_func:
        .word 0x0
        clrl _cnt
        clrl r0
L5:
        incl r0
        cmpl r0,$4
        jleq L5
        ret
        .size   _func , . - _func
.comm _cnt,4 


_cnt is ending up unchanged.  

(speculation begins here, please don't flame too badly)
I've looked through rtl dumps, and it looks like the "set" insn which 
sets cnt to what it should be (after the loop) gets trapped with 
a code_label with 0 uses:

(jump_insn 16 45 17 (return) -1 (nil)
    (nil))

(barrier 17 16 34)

(note 34 17 56 NOTE_INSN_LOOP_END -1347440721)

(code_label 56 34 58 7 "" "" [0 uses])

(insn 58 56 37 (set (mem/f:SI (symbol_ref:SI ("cnt")) 4)
        (reg/v:SI 23)) -1 (nil)
    (nil))

(note 37 58 0 0x40349580 NOTE_INSN_BLOCK_END -1347440721)

This code_label and the set insn soon get removed erroneously, since the 
"return" pattern for the vax just outputs a single instruction and has no
qualifying statements.  Looking around, I see that vax is the only 
architecture which has such a simple return insn pattern and is not 
completely disabled in the configure script.  Everything else seems to 
at the very least check reload_completed.

I made the vax's return pattern check reload_completed as well, but that 
wasn't enough; other "ret" instructions weren't being output when they 
should have been, so lots of other things were breaking.  To fix that problem,
I added an "epilogue" expansion which just expanded to (return).  So far,
that has given me passable results at -O0, -O1, and -O2.. but it seems
like an awful dirty hack.  Could anyone shed some light?

thanks
bjc@pobox.com