On 9/17/21 8:54 AM, Richard Earnshaw wrote:
On 16/09/2021 16:44, Martin Sebor via Gcc wrote:
On 9/14/21 2:10 AM, Andrew Pinski via Gcc wrote:
Hi all,
I am doing some bugzilla cleanup. This includes disabling some
components and some versions for new bugs.
So far I have disabled versions before GCC 4 because we have not had a
report from someone for those versions in over 7 years. I disabled
some versions which are about developmental branches which are
inactive too.
I also disabled the java, libgcj, fastjar, libmudflap, treelang and
libf2c components.
I am in the process of moving away from having an inline-asm component
to an inline-asm keyword instead; this was suggested on IRC and I
agree. After the current open bugs have moved away from the
inline-asm component, I will disable it also.
If anyone else has any other suggestions that should be done, please
let me know and I will look into doing it.
Re: Keywords: I find it useful to differentiate between two kinds of
diagnostic bugs: false positives and false negatives (the latter for
existing warnings that don't trigger when intended, as opposed to
requests to enhance existing warnings or add new ones). I've been
using Personal Tags for this but it might be useful to others as
well. If you agree and add the corresponding new keywords
(false-positive and false-negative) I'll set them based on my Tags.
One other suggestion: every once in a while someone asks if
ice-on-invalid-code bugs apply to syntactically well-formed code that
has undefined behavior (I don't believe it does). It would help to
clarify the Description for this Keyword (and, correspondingly, for
ice-on-valid). E.g., something like
ice-on-invalid-code: ICE on code that is not syntactically valid.
ice-on-valid-code: ICE on code that is syntactically valid.
What about syntactically valid but semantically invalid code? I'd call
that ICE-on-invalid as well.
My understanding of the "valid" in the keyword is that it refers
only to syntactic validity AKA well-formedness.
But I only set the keyword to help with bug triage, I don't actually
rely on it for anything myself. The interpretation should be based
on what its main consumers use it for. I expect Richard Biener (CC'd)
might be using it for his release planning activities and so might
want to weigh in on this.
Martin
PS In bugs reported for my code in the middle end (often having to
do with detecting semantically invalid AKA undefined code), I use
ice-on-valid for well-formed test cases with undefined behavior.
I set ice-on-invalid only for the less common cases of syntactically
invalid code that somehow makes it into the middle-end or that's
analyzed in the front end. If this isn't right I'd like to know.
