This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Results for egcs-2.93.10 19990307 (gcc2 ss-980929 experimental) testsuite on i686-pc-sco3.2v5.0.5



  In message <19990308214634.27112.qmail@deer>you write:
  > What is the semantic value of "a new test" to you and others?  The
  > main one I know about is "if it's a new test and it's failing, it
  > probably isn't a regression".
Basically correct.

ie, I know with reasonable accuracy what tests fail on targets I work with
a lot, and they're mostly restricted to tests added since mid 1998.  If
something from 1997 pops up, then I'll make the assumption that I've broken
something and that it needs to be fixed asap before I lose too much context
and forget the details of whatever recent changes I've made.


  > But if there is more semantic value to "a new test" than that, I'd
  > like to know what it is.  I don't want to add a whole bunch more
  > tests in the near future in a mistaken manner....
Well, since I suspect you're the primary person that digs into the g77 failures
I think doing things in a manner that works best for you is probably best for
the project.

  > The one that crashes in mark_edges or whatever seems to be due to
  > code in flow.c expecting a jump_insn matching a (set (pc) (label_ref...))
  > having JUMP_LABEL non-null, but it is null in one of the cases.  I've
  > not explored this much further than that.  (The crash happens when
  > compiling "SUBROUTINE FUNCTION PROGRAM" or whatever nonsense is
  > used to try and confuse a Fortran front end.)  It's not clear to me
  > the bug is really in the recent flow changes -- it might be a latent
  > bug elsewhere, e.g. in local_alloc, because the original insn
  > was (set (pc) (reg...)), and the reg part was rewritten to the label_ref
  > in time for the .lreg and .greg dumps.  Haven't even looked at the docs
  > to see what they say about the RTL requirements in this area (are
  > they up-to-date?).
Hmm.  I'd suspect cse & jump since the first is the most likely pass to
change an indirect/table jump into a jump to a known location.  And the
second since it should have updated the jump label (if cse changes jumps
it's supposed force jump to be re-run).

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]