[FYI] bugzilla cleanup

[FYI] bugzilla cleanup

[Andrew Pinski]

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.

Thanks,
Andrew

Re: [FYI] bugzilla cleanup

[Martin Jambor]

Hi,

On Tue, Sep 14 2021, Andrew Pinski via Gcc wrote:
> Hi all,
>   I am doing some bugzilla cleanup.  This includes disabling some
> components and some versions for new bugs.

Thanks a lot!

> 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.
>

I still plan to split the 26163 "SPEC" meta bug into two, one for real
missed-optimizations and another for ICEs/miscompilations - but I will
not complain if anyone does that before I get to it :-)

Martin

Re: [FYI] bugzilla cleanup

[Martin Sebor]

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.

Martin

Re: [FYI] bugzilla cleanup

[NightStrike]

On Thu, Sep 16, 2021 at 11:45 AM Martin Sebor via Gcc <gcc@gcc.gnu.org> wrote:
> ice-on-invalid-code: ICE on code that is not syntactically valid.
> ice-on-valid-code: ICE on code that is syntactically valid.

Presumably, the distinction is there because more attention would get
paid to the latter over the former.  An alternative would be to just
have "ice", and thus perhaps it might cause more overall bugs to get
fixed in the end.

Re: [FYI] bugzilla cleanup

[Richard Earnshaw]

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

Re: [FYI] bugzilla cleanup

[Martin Sebor]

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.

Re: [FYI] bugzilla cleanup

[Richard Biener]

On September 17, 2021 6:30:21 PM GMT+02:00, Martin Sebor <msebor@gmail.com> wrote:
>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.

Yes. 

>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.

In fact syntactically valid code should not ICE and that's as important as semantically valid code not ICE. 

>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.

That's correct. 

Richard. 

Re: [FYI] bugzilla cleanup

[Eric Gallager]

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