On Thu, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc <gcc@gcc.gnu.org> 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. >
Oh right, if we're promoting Personal Tags to keywords, I have one that I think could be useful: "need-better-backtrace", for cases when the reporter posted a backtrace, but built their GCC without debugging symbols, meaning that the backtrace is incomplete, i.e., missing stuff like line info and/or arguments to functions. > 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. > > Martin
