When compiling a particular function with -O2 and targetting THUMB, I found that the compiler
generated incorrect code. In particular it looks like an iteration variable that was strength-reduced ends
up off by one: In each iteration, the value used for the variable in question appears to be the value that
ought to be used in the *subsequent* iteration.
The line in question that gets erroneously compiled is:
ic = scan->ics[n];
I'll attach the raw source (pared down but still verified to compile) and the annotated assembly file as
soon as I figure out how to do that with bugzilla.

Better compile line:
arm-elf-gcc -save-temps -W -Wall -c jpeg_decode_4.c -mthumb -O2
BTW, out of curiosity, what was wrong with my "Host" and "Build" triples? (Apologies: I was unable to
find good documentation about what to fill in for them.)

I've now determined that changing the optimization options to "-O2 -fno-strength-reduce" makes the
problem go away and that changing the optimization options to "-O1 -fstrength-reduce" makes the
problem manifest itself.

Subject: Re: THUMB -O2: strength-reduced
iteration variable ends up off by 1
On Wed, 2004-06-16 at 00:18, danfuzz at milk dot com wrote:
> BTW, out of curiosity, what was wrong with my "Host" and "Build" triples? (Apologies: I was unable to
> find good documentation about what to fill in for them.)
Nothing in particular. But this problem is independent of the host and
build so it makes life easier in this case to leave them unspecified.
This way maintainers looking for host-specific problems won't match on
bugs that aren't interesting to them.

Ok, scratch that thing about options being out-of-date. I didn't realize (until rereading the docs a little
more closely and then verifying in the sources) that "-Os" turns on optimizations that aren't available
via any fine-grained "-f" option. (Maybe that should be changed? Why not have "-foptimize-size"?)

Created attachment 6595[details]
annotated RTL dumps for m2.c
I believe I've managed to narrow down when the error gets introduced to after
local register allocation and perhaps during global register allocation.
Excerpts of -dl and -dg output with commentary are attached.

I've now determined that adding "-fnew-ra" to the compile options for m2.c makes the problem go
away. However, I'm reticent to switch to using that option across-the-board since the documentation
implies that it's not yet ready for prime time.

...though it *does* look like the problem in this case is introduced in the function reload(), based on
adding an rtl dump immediately before and immediately after the call to reload() inside global_alloc()
(line 606 of global.c in the 3.4.0 sources).

Confrimed. Also occurs on the trunk with similar compilation options.
I dont' think this is related to the two reports you cite. In fact, I suspect
it's a problem with validating that a register hasn't already been allocated for
use in reloads in the current insn. Looking earlier in the greg dump (m2.c) we see:
Reloads for insn # 44
Reload 0: LO_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 1), can't combine,
secondary_reload_p
reload_reg_rtx: (reg:SI 2 r2)
Reload 1: reload_in (SI) = (reg/v/f:SI 102 [ xb ])
reload_out (SI) = (reg/v/f:SI 102 [ xb ])
BASE_REGS, RELOAD_OTHER (opnum = 1)
reload_in_reg: (reg/v/f:SI 102 [ xb ])
reload_out_reg: (reg/v/f:SI 102 [ xb ])
reload_reg_rtx: (reg:SI 1 r1)
secondary_out_reload = 0
Reload 2: reload_out (SI) = (reg/v:SI 106 [ y ])
LO_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (reg/v:SI 106 [ y ])
reload_reg_rtx: (reg:SI 2 r2)
and from this we can see that r2 is allocated (reload_reg_rtx) for use by both
reload 0 and reload 2.
As an aside, it's not entirely obvious to me why reload thinks that the first
reload is needed at all in this case: it could be in some circumstances, but in
this instance we can directly load/store the base address from the stack, and
directly store the result to the stack. A third reload seems to be redundant.

I have no idea if this is useful information or not, but it looks like the problem is introduced during the
call to reload_as_needed() on line 1061 of reload1.c (of the 3.4.0 sources).
Sorry for being thick, but it is unclear to me whether gcc's state is already messed up by the time the
call gets made and the call does the "right" thing with bad data, or whether it is this call itself which
actually causes the problem in the first place.

Subject: Re: THUMB -O2: strength-reduced iteration
variable ends up off by 1
On Mon, 2004-08-23 at 20:24, mmitchel at gcc dot gnu dot org wrote:
> ------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-08-23 19:24 -------
> Richard, is there any reason not to apply this patch before 3.4.2?
No. I wanted to give it time to gestate on the mainline for a while,
but it's done that now and now thrown up any problems, so I'll check it
in.
R.