PR# 16552 Inlining call to deferred routine merged with effective routine yields wrong results

A system has a PARENT class with a deferred routine and an effective routine
that just returns the value of one of the class attributes.  A child class renames the
deferred routine into the effective one, causing them to be merged.  A call to
the parent deferred routine that cannot be staticly bound is not inlined correctly,
causing system execution to produce the wrong results.

This needs to be fixed for 6.6.  We ran into it in real code, but fortunately that system
is only used for regression testing.

Added eweasel test final087 for this bug.

Run eweasel test final087.

This bug was fixed in rev 86325 by preventing inlining in the case that caused
incorrect results.  So you may want to close it, unless you plan to later allow
inlining (which is apparently a more complicated change).

Reopening this bug since the associated eweasel test final087 fails with
rev 83315.

For the record, here is what seems to be the crucial difference in the generated code.

Old (gives incorrect results):

        /* INLINED CODE (index) */
        ti4_1 = (EIF_INTEGER_32)  0;
        ti4_1 = *(EIF_INTEGER_32 *)(RTCV(tr1)+ _LNGOFF_2_1_0_0_);
        /* END INLINED CODE */

New (gives correct results):

        /* INLINED CODE (index) */
        ti4_1 = (EIF_INTEGER_32)  0;
        ti4_1 = *(EIF_INTEGER_32 *)(RTCV(tr1)+ _LNGOFF_1_2_0_0_);
        /* END INLINED CODE */

It seems that there is a difference in the offset calculation, such that rev 82636
now gives correct results.

I'll close it but I'm like you that it seems to be by sheer luck. The other test that exhibit this is final041.

The eweasel test for this bug (final087) passes with rev 82636, but I didn't
see any specific fix for it.  Please close if you think the bug is really fixed,
rather than the test passing by luck.