patch that caused regression PR c/8730

patch that caused regression PR c/8730

[Janis Johnson]

The regression reported in PR c/8730 showed up starting
with this large patch from long, long ago:

Sat Nov 27 08:38:26 1999  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>

	* fold-const.c (negate_expr, associate_trees, extract_muldiv): New.
	(split_tree): Completely rework to make more general.
	(make_range, fold): Call negate_expr.
	(fold, case NEGATE_EXPR): Simplify -(a-b) is -ffast-math.
	(fold, associate): Call new split_tree and associate_trees.
	(fold, case MULT_EXPR, case *_{DIV,MOD}_EXPR): Call extract_muldiv.

Here's a small test case that causes the compiler to ICE when compiled
on i686-linux with the mainline:

-------------------
void foo() {
  void *bar (int i, int A[1][i]) { return A[0]; };
};
-------------------

The same patch causes the behavior to change with the
submitter's larger test case.

Output from the the mainline:

8730.c: In function `bar':
8730.c:2: internal compiler error: in expand_expr, at expr.c:6823
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

I've added this information to the PR.

Janis

Re: patch that caused regression PR c/8730

[Richard Kenner]

    The regression reported in PR c/8730 showed up starting
    with this large patch from long, long ago:

    Sat Nov 27 08:38:26 1999  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>

	* fold-const.c (negate_expr, associate_trees, extract_muldiv): New.

    void foo() {
      void *bar (int i, int A[1][i]) { return A[0]; };
    };

I looked at this and am quite confused how this is supposed to work with the
new function-at-a-time processing.  I don't understand how the above patch
related to this, though.

What's happening is that a SAVE_EXPR is being made to compute the size of
the inner array.  Its SAVE_EXPR_CONTEXT is foo, not bar, but when it's 
evaluated for the first time in bar, it blows up.

It's true that SAVE_EXPR is made in extract_muldiv, but it's made from a
SAVE_EXPR that has the save SAVE_EXPR_CONTEXT.

I believe that these SAVE_EXPRs should have SAVE_EXPR_CONTEXT of bar, the
inner function.

Somebody who understand the C front end's function-at-a-time handling should
look at this.