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


>I don't have a strong opinion either way.  I'd lean towards updating the names
>as they're added to the egcs testsuite -- that makes it very clear it's a new
>test without actually having to go find it in the ChangeLog.

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".  That's exactly the default impression
I want to *avoid* when adding *old* tests, from my private suite, to
the repository, especially when I do so because I discover a regression
in a recent snapshot!  That is, I want the old tests to look, at first
blush, like old tests, so they'll look like the regressions they
really are (though they're not, in the strict sense of "regressions
within the egcs test suite").

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....

>But since I typically don't dive into a Fortran test unless it's a regression
>due to my changes or someone tells me it's a backend bug I'll go along with
>whatever you prefer.

Except for my execute/compile goof, the tests added in the recent
snapshot are new regressions with that snapshot -- compile-time
crashes in both cases.  I've already posted to egcs-bugs about this,
though.

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?).

        tq vm, (burley)


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