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

["bangerth at dealii dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From bangerth at dealii dot org  2004-05-26 19:09 -------
If a patch is reverted, the PR must be reopened anyway, and the person 
doing so should ideally also adjust the fields that this changes. Note 
that bugs should really not re-appear in other circumstances, since patches 
are supposed to come with testcases. 
 
The target milestone is always the first upcoming version on the first 
active branch on which the bug appears, unless the release manager for 
that branch decides that this bug can't be fixed for this release. Note 
that the target milestone describes an _intent_: "we'd like to have this 
bug fixed by that version". The known-to-work field describes a _fact_: 
"This bug has been tested against these versions/branches and has been 
verified to trigger/to not trigger the bug there". 
 
Thus, the known-to-* fields are not meant to indicate something to a 
user, but rather to fellow developers, namely where we have checked the 
bug and for example whether a patch has to be applied to the 3.4 or 3.3 
branch as well since the bug exists there as well. If we have verified that 
the bug doesn't exist there, that means that the developer does not have 
to spend cycles on re-checking this. 
 
I understand that the fact that we also use branch-names and not only 
release names in these fields can in a few occasions be confusing.  
However, I cannot imagine a significant number of cases where us setting 
the known-to-work field for branch x.y will be wrong for release x.y 
because the bug has reappeared. I believe that these should be very 
infrequent cases, and that we are much better served if we use this 
field to indicate where people have tested against a certain bug. 
 
W. 

-- 


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