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.

R.

Martin

Reply via email to