Re: Testsuite policy - do we care if obscure options work?

["Tim Prince" <tprince at computer dot org>]

Another question about policy:  which obscure combinations of options
would even be considered for testsuite?  I ran into one today, using
yesterday's snapshot, where adding -fno-automatic to an otherwise
working group of options produces a SIGSEGV.  Yes, I found the 30 year
old bug which required -fno-automatic.  No, this code still won't run
with the Compaq compiler other than in debug mode, but the Compaq
compiler in debug mode runs significantly faster (on this messy 16000
source line code) than any g77.

To me, solving the problems with -funroll-loops would rank higher
than -fno-automatic.  Even that appears to be low on the priority list,
but there's no way the performance goal in comparison with gcc-2.95.2
will be reached without it becoming reliable.

Tim Prince

----- Original Message -----
From: "Mark Mitchell" <mark@codesourcery.com>
To: <David.Billinghurst@riotinto.com.au>
Cc: <gcc@gcc.gnu.org>
Sent: Thursday, June 15, 2000 4:59 PM
Subject: Re: Testsuite policy - test case now passes but bug remains


>
>   A question about testsuite policy/etiquette?
>
>   Recently I found a g77 bug, produced a simple testcase and submitted
it to
>   the g77 testsuite as 20000601-1.f
>    http://gcc.gnu.org/ml/gcc-bugs/2000-05/msg01005.html .  The problem
seems
>   restricted to mips-sgi-irix6.5 with -mabi=64.  Now the testcase
passes but
>   the original bug remains.
>
>   Should I:
>
>   * submit a new testcase (probably not)
>
> Actually, that's the right answer.  You submitted a test-case for a
> bug.  That bug was fixed -- but some other bug is still there.  Submit
> a second test-case for the second bug.  Even if the causes are
> related, it's good to have lots of test coverage for the parts of the
> compiler that have historically been weak.
>
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com