From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10450 invoked by alias); 26 May 2004 21:02:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10438 invoked by alias); 26 May 2004 21:02:14 -0000 Date: Thu, 27 May 2004 14:02:00 -0000 Message-ID: <20040526210214.10437.qmail@sourceware.org> From: "hp at bitrange dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040505140818.15296.hp@gcc.gnu.org> References: <20040505140818.15296.hp@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/15296] [3.4 only] Delayed branch scheduling causing invalid code on cris-* X-Bugzilla-Reason: CC X-SW-Source: 2004-05/txt/msg03124.txt.bz2 List-Id: ------- Additional Comments From hp at bitrange dot com 2004-05-26 21:02 ------- Subject: Re: [3.4 only] Delayed branch scheduling causing invalid code on cris-* On Wed, 26 May 2004, bangerth at dealii dot org wrote: > 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". Well, that's what I've been trying to say... The known-to fields should state facts, but your current usage does not follow the intent you state: when you write release identifiers rather than branch identifiers, it can't be a *fact* until the release is done. Can you consider e.g. writing 3.3-branch, not 3.3.4 in the known-to-work field? It doesn't have to be an exact branch identifier as long as it's unique. Perhaps also consider using the known-to-fail field for releases only? If not, you'd have to iterate over all bugs to fix known-to-fail fields for bugs that "disappear" for that field to state a fact! > 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. The problem seems to be that you use non-unique terms in those fields: your refer to the 3.3 branch as 3.3.4, which will hopefully be the name of a release as well. Still, please document whatever usage of yours, supposedly in management.html. Maybe I should open a bug report for that? (No, *I* don't want to document it since I still consider this usage confusing if not wrong, if nothing else than that it's easy to mistakenly remove a "known to fail" field for a release known to fail (QED). At least until you stop using the same name for releases as branches.) brgds, H-P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15296