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