Your change
Jason Eckhardt
jle@cygnus.com
Sun Mar 19 12:07:00 GMT 2000
On Sun, 19 Mar 2000, Mark Mitchell wrote:
> >>>>> "Jason" == Jason Eckhardt <jle@cygnus.com> writes:
>
> Jason> On Sat, 18 Mar 2000, Mark Mitchell wrote:
>
> >> Jason --
> >>
> >> Sat Mar 18 14:38:00 2000 Jason Eckhardt <jle@cygnus.com>
> >>
> >> * bb-reorder.c (reorder_basic_blocks): Update PREV_INSN as well
> >> as NEXT_INSN. Update last insn in chain.
> >>
> >> This change broke g++.jason/inline3.C on i686-pc-linux-gnu.
> >>
>
> Now I can't replicate any behavior change relating to your change
> either -- so I must have been dreaming, or there must have been
> something else going on. I'll investigate further.
>
> Thanks for your patience,
>
> --
> Mark Mitchell mark@codesourcery.com
> CodeSourcery, LLC http://www.codesourcery.com
>
My guess as to what happened:
1. inline3.C failed spuriously (too many processes, who knows).
2. The nightly testing methodology does not automatically re-run
apparent regressions to identify spurious or non-deterministic failures.
3. Backing out the change made test pass; leading to the (likely false)
conclusion that the change caused the failure in the first place.
4. If #2 above had been done before backing out the change, I believe the
testcase would have passed.
Note that -freorder-blocks is disabled by default. The code path in the
patch can only be
executed with -freorder-blocks enabled. The C++ tests, nor C tests, enable
this by default. It seems unlikely, then, that this code path executed
during that testcase.
If #2 is not part of the testing methodology, it ought to be. Its typical
practice for gaining stronger regression results.
jason.
More information about the Gcc-bugs
mailing list