Preincrement of array element

[Alexandre Petit-Bianco]

Boehm, Hans writes:

> Did anyone ever come up with a patch for that?  It seems like a
> fairly fundamental problem.  Or does this work for other people?

I worked on it on several occasions but couldn't solve the problem.

> It seems like a fairly fundamental problem.  Or does this work for
> other people?

I agree it is. I'm now pretty sure it doesn't work for all platforms,
which points toward a FE problem (the tree nodes we generate aren't
legal) or a middle-end problem (it doesn't know how to handle our tree
node sequence properly.)

> Here's a simple example that's well suited for debugging:

That's what I'm using. 

> The inc function is clearly miscompiled.  As a nonexpert, and based
> on the fact that gcj -C works, the tree looks OK to me.  The RTL
> code is wrong, in that the store back into a[i] has been dropped.
> So far I had a bit of trouble following the translation process in
> more detail.

Yeah. The right insns are produced by the compiler but latter dropped
(regardless of the optimization level.) I've been working on this
sporadically but never couldn't find what could fix it -- it could be
a middle-end bug. Note that the index has to be a variable, a scalar
won't trigger the bug.

The bottom line is that the SAVE_EXPR of the array base that we do in
order to enforce certain Java semantics (such as (a=b)[n] IIRC) seems
to upset gcc. Removing this SAVE_EXPR produces a compiler that
miscompiles libgcj (libgcj crashes right after start-up.)

I still have some other things to try before I ping the
middle/back-end people about it, which I should do shortly anyways.

FYI, here's an email I sent to the person who worked on making arrays
behaving the way Java expects them to behave.

./A

I've been looking several times at java/3096:

  http://gcc.gnu.org/ml/java-prs/2001-q2/msg00070.html

and I can't really figure it out.

Pre-incrementing an array whose index is a variable doesn't work when
building to native, regardless of -f{no-}bounds-check and -Ox. It
works if the index is a scalar, it works when going to bytecode.

The assembly shows that the code is simply not emitted. In
expand_increment, around 9309 it is established that the incremented
part is a copy. Later, around 9351, op0_is_copy let us enter the if
clause where newexp is built (post is 0 and single_insn is 1,
bad_subreg is 0) and:

9374      temp = expand_assignment (incremented, newexp, ! post && ! ignore , 0);

should do the trick, but `expand_assignment (to, from, ...)' doesn't
seem to be suited to handle the situation very well. At that stage,
`to' is a SAVE_EXPR built early in expand_increment by calling
stabilize_reference on the incremented part. Is there something that
should be done (early) in expand_assignment to handle SAVE_EXPRs? Or
should the problem be dealt with earlier on?