This is the mail archive of the gcc-bugs@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]
Other format: [Raw text]

[Bug rtl-optimization/15296] [3.4 only] Delayed branch scheduling causing invalid code on cris-*


------- Additional Comments From hp at bitrange dot com  2004-05-26 18:40 -------
Subject: Re:  [3.4 only] Delayed branch scheduling
 causing invalid code on cris-*

On Wed, 26 May 2004, bangerth at dealii dot org wrote:
> All of us bugzilla people quite frequently use the known-to-{work,fail}
> fields to fill which _branches_ work. For example, if something is
> known to fail with the 3.4.0 release but to be fixed on mainline, then
> 3.5.0 will be listed in the known-to-work field. This actually makes some
> sense, since if it is fixed on the mainline, then there needs to be a
> testcase in the testsuite which (at least ideally) should prevent this
> problem from re-appearing on mainline, thus guaranteeing that the actual
> 3.5.0 release will also work.

You may think it makes sense, but it is still confusing:
consider the bug re-appearing; perhaps because the fix was
reverted.  Then later, someone looks at bugzilla to choose a
"safe" version regarding the bug.  That person would be fooled
by the assertion that a bug is fixed in a version where the
testcase provingly fails.  Hence "known to work/fail" should
only be used for released versions. That is, unless extra work
is done at the release (or for any change that could possibly
affect the "known to" facts), checking the "known to work"
fields, adjusting them when necessary.

Besides, how do you compare the "known to work" field with the
"target version" field?  What about the apparent redundancy?

>
> This procedure may not be documented, but us bugzilla guys all seem to use
> it.

Which doesn't make it correct or any less confusing.

Anyway, if you stand by that usage, please document it for the
benefit of everyone else.  I'd like to be able to explain the
person reporting the bug to me (or anyone, for example a
manager), without refering to folklore.  1/2 :-)

brgds, H-P


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15296


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