Re: Killing old dead bugs

[Eric Gallager]

On 7/19/17, Yuri Gribov  wrote:
> On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager 
> wrote:
>> On 7/18/17, Yuri Gribov  wrote:
>>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor  wrote:
 On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>
> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor 
> wrote:
>>
>> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>>
>>>
>>> Hi Mikhail,
>>>
>>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
>>> wrote:


 Hi. Yes, bug maintenance is appreciated. See this message and
 replies
 to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>>>
>>>
>>>
>>> Replies in your link suggest to leave a final comment in bugs with
>>> explanatory suggestion to close them so that maintainers who read
>>> gcc-bugs list hopefully notice them and act appropriately.
>>> Unfortunately I found this to _not_ work in practice. Below you can
>>> see a list of bugs I've investigated (and often bisected) in the
>>> past
>>> weeks - none of them were closed by maintainers (or at least
>>> commented).
>>>
>>> So I'm afraid we have to conclude that there's no working process to
>>> close stale bugs in place (which may be one of the reasons of
>>> bugcount
>>> growth).
>>
>>
>>
>> The informal process that some (most?) of us have been following
>> is to close them with a comment explaining our rationale.
>> It's good to fill in the Known to fail/Known to work versions if they
>> can be determined.  Mentioning the commit that fixed the bug as
>> you did for the bugs below is ideal.  Adding a test case if one
>> doesn't exist in the test suite is also very useful, though quite
>> a bit more work.  In my experience, if a bug is closed that should
>> stay open, someone usually notices pretty quickly and reopens it,
>> so I wouldn't be too worried about doing something wrong.
>
>
> Martin,
>
> Firstly, thanks for detailed explanation.
>
> What to do about bugs originating in upstream packages?  I noticed
> they sometimes get closed with "RESOLVED MOVED" resolution
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
> does not happen and they just hang in tracker forever for no good
> reason.
>
> Actually what I tried to emphasize is that it's impossible for a
> casual commiter (who does not have maintainer access to Bugzilla i.e.
> rights to close bugs) to contribute to project by cleaning stale bugs,
> because requests to close them are mostly ignored (because
> maintainers, obviously, have much more interesting work to do).


 I take your point.  I didn't realize closing bugs was restricted.
 Given the work you've done on the bugs below (and elsewhere) you
 should be able to close them.  If you aren't and would like to be
 able to, please request it by emailing overse...@gcc.gnu.org ((at
 least I think that's the right way to go about it), or follow up
 here and I'm sure someone with the right karma will make it happen.
>>>
>>> Jonathan also mentioned something not immediately obvious in IRC:
>>> logging into BZ with gcc.gnu.org account provides elevated privileges.
>>> So if you have write access, you should get extra BZ rights for free.
>>>
>>
>> Is there a way to do this with a password thru a graphical web
>> browser? The instructions I found on the SVN write page
>>  only mentioned ssh-ing into the
>> server. It says "Your gcc.gnu.org account... is what you use for
>> Bugzilla" but doesn't actually say how to do that.
>
> AFAIR the only way to login to BZ with GNU account is to reset
> password (so that BZ sends reset email to the linked account which you
> specified via `ssh usern...@gcc.gnu.org email ...').
>

Thank you; your advice worked! I shall now proceed to killing some old
dead bugs of my own, since this conversation seemed to encourage it...

>> I tried using the
>> same password as I do for the Bugzilla account linked to the email
>> that my gcc.gnu.org account forwards to (this one), but that didn't
>> work. Sorry if I'm missing something obvious...
>> The process for managing bugs is in more detail described here:
>>
>>   https://gcc.gnu.org/bugs/management.html
>>
>> If you think it should be clarified in some way please feel free
>> to send in a patch.
>>
>> Martin
>>
>>
>>>
>>> * Bug 41992 - ICE on invalid dereferencing of void *
>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
>>> * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
>>> underlying type
>>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
>>> * Bug 61693 - [asan] is 

Re: Killing old dead bugs

[Yuri Gribov]

On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager  wrote:
> On 7/18/17, Yuri Gribov  wrote:
>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor  wrote:
>>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:

 On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:
>
> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>
>>
>> Hi Mikhail,
>>
>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
>> wrote:
>>>
>>>
>>> Hi. Yes, bug maintenance is appreciated. See this message and replies
>>> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>>
>>
>>
>> Replies in your link suggest to leave a final comment in bugs with
>> explanatory suggestion to close them so that maintainers who read
>> gcc-bugs list hopefully notice them and act appropriately.
>> Unfortunately I found this to _not_ work in practice. Below you can
>> see a list of bugs I've investigated (and often bisected) in the past
>> weeks - none of them were closed by maintainers (or at least
>> commented).
>>
>> So I'm afraid we have to conclude that there's no working process to
>> close stale bugs in place (which may be one of the reasons of bugcount
>> growth).
>
>
>
> The informal process that some (most?) of us have been following
> is to close them with a comment explaining our rationale.
> It's good to fill in the Known to fail/Known to work versions if they
> can be determined.  Mentioning the commit that fixed the bug as
> you did for the bugs below is ideal.  Adding a test case if one
> doesn't exist in the test suite is also very useful, though quite
> a bit more work.  In my experience, if a bug is closed that should
> stay open, someone usually notices pretty quickly and reopens it,
> so I wouldn't be too worried about doing something wrong.


 Martin,

 Firstly, thanks for detailed explanation.

 What to do about bugs originating in upstream packages?  I noticed
 they sometimes get closed with "RESOLVED MOVED" resolution
 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
 does not happen and they just hang in tracker forever for no good
 reason.

 Actually what I tried to emphasize is that it's impossible for a
 casual commiter (who does not have maintainer access to Bugzilla i.e.
 rights to close bugs) to contribute to project by cleaning stale bugs,
 because requests to close them are mostly ignored (because
 maintainers, obviously, have much more interesting work to do).
>>>
>>>
>>> I take your point.  I didn't realize closing bugs was restricted.
>>> Given the work you've done on the bugs below (and elsewhere) you
>>> should be able to close them.  If you aren't and would like to be
>>> able to, please request it by emailing overse...@gcc.gnu.org ((at
>>> least I think that's the right way to go about it), or follow up
>>> here and I'm sure someone with the right karma will make it happen.
>>
>> Jonathan also mentioned something not immediately obvious in IRC:
>> logging into BZ with gcc.gnu.org account provides elevated privileges.
>> So if you have write access, you should get extra BZ rights for free.
>>
>
> Is there a way to do this with a password thru a graphical web
> browser? The instructions I found on the SVN write page
>  only mentioned ssh-ing into the
> server. It says "Your gcc.gnu.org account... is what you use for
> Bugzilla" but doesn't actually say how to do that.

AFAIR the only way to login to BZ with GNU account is to reset
password (so that BZ sends reset email to the linked account which you
specified via `ssh usern...@gcc.gnu.org email ...').

> I tried using the
> same password as I do for the Bugzilla account linked to the email
> that my gcc.gnu.org account forwards to (this one), but that didn't
> work. Sorry if I'm missing something obvious...
> The process for managing bugs is in more detail described here:
>
>   https://gcc.gnu.org/bugs/management.html
>
> If you think it should be clarified in some way please feel free
> to send in a patch.
>
> Martin
>
>
>>
>> * Bug 41992 - ICE on invalid dereferencing of void *
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
>> * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
>> underlying type
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
>> * Bug 61693 - [asan] is not intercepting aligned_alloc
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
>> * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
>> format mismatch between libasan and GCC
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
>> * Bug 78028 - ASAN doesn't find memory leak
>> 

Re: Killing old dead bugs

[Jonathan Wakely]

On 19 July 2017 at 19:15, Eric Gallager wrote:
> On 7/18/17, Yuri Gribov  wrote:
>> Jonathan also mentioned something not immediately obvious in IRC:
>> logging into BZ with gcc.gnu.org account provides elevated privileges.
>> So if you have write access, you should get extra BZ rights for free.
>>
>
> Is there a way to do this with a password thru a graphical web
> browser?

What "this" are you asking about?

> The instructions I found on the SVN write page
>  only mentioned ssh-ing into the
> server. It says "Your gcc.gnu.org account... is what you use for
> Bugzilla" but doesn't actually say how to do that.

How to do what?

> I tried using the
> same password as I do for the Bugzilla account linked to the email
> that my gcc.gnu.org account forwards to (this one), but that didn't
> work. Sorry if I'm missing something obvious...

Don't use the bugzilla account linked to the email address it forwards
to, use the bugzilla account linked to the @gcc.gnu.org email address.

Log in to bugzilla using $u...@gcc.gnu.org and you have privs. If you
don't know the password, reset it.

Re: Killing old dead bugs

[Eric Gallager]

On 7/18/17, Yuri Gribov  wrote:
> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor  wrote:
>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>>
>>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:

 On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>
>
> Hi Mikhail,
>
> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
> wrote:
>>
>>
>> Hi. Yes, bug maintenance is appreciated. See this message and replies
>> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>
>
>
> Replies in your link suggest to leave a final comment in bugs with
> explanatory suggestion to close them so that maintainers who read
> gcc-bugs list hopefully notice them and act appropriately.
> Unfortunately I found this to _not_ work in practice. Below you can
> see a list of bugs I've investigated (and often bisected) in the past
> weeks - none of them were closed by maintainers (or at least
> commented).
>
> So I'm afraid we have to conclude that there's no working process to
> close stale bugs in place (which may be one of the reasons of bugcount
> growth).



 The informal process that some (most?) of us have been following
 is to close them with a comment explaining our rationale.
 It's good to fill in the Known to fail/Known to work versions if they
 can be determined.  Mentioning the commit that fixed the bug as
 you did for the bugs below is ideal.  Adding a test case if one
 doesn't exist in the test suite is also very useful, though quite
 a bit more work.  In my experience, if a bug is closed that should
 stay open, someone usually notices pretty quickly and reopens it,
 so I wouldn't be too worried about doing something wrong.
>>>
>>>
>>> Martin,
>>>
>>> Firstly, thanks for detailed explanation.
>>>
>>> What to do about bugs originating in upstream packages?  I noticed
>>> they sometimes get closed with "RESOLVED MOVED" resolution
>>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
>>> does not happen and they just hang in tracker forever for no good
>>> reason.
>>>
>>> Actually what I tried to emphasize is that it's impossible for a
>>> casual commiter (who does not have maintainer access to Bugzilla i.e.
>>> rights to close bugs) to contribute to project by cleaning stale bugs,
>>> because requests to close them are mostly ignored (because
>>> maintainers, obviously, have much more interesting work to do).
>>
>>
>> I take your point.  I didn't realize closing bugs was restricted.
>> Given the work you've done on the bugs below (and elsewhere) you
>> should be able to close them.  If you aren't and would like to be
>> able to, please request it by emailing overse...@gcc.gnu.org ((at
>> least I think that's the right way to go about it), or follow up
>> here and I'm sure someone with the right karma will make it happen.
>
> Jonathan also mentioned something not immediately obvious in IRC:
> logging into BZ with gcc.gnu.org account provides elevated privileges.
> So if you have write access, you should get extra BZ rights for free.
>

Is there a way to do this with a password thru a graphical web
browser? The instructions I found on the SVN write page
 only mentioned ssh-ing into the
server. It says "Your gcc.gnu.org account... is what you use for
Bugzilla" but doesn't actually say how to do that. I tried using the
same password as I do for the Bugzilla account linked to the email
that my gcc.gnu.org account forwards to (this one), but that didn't
work. Sorry if I'm missing something obvious...

 The process for managing bugs is in more detail described here:

   https://gcc.gnu.org/bugs/management.html

 If you think it should be clarified in some way please feel free
 to send in a patch.

 Martin


>
> * Bug 41992 - ICE on invalid dereferencing of void *
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
> * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
> underlying type
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
> * Bug 61693 - [asan] is not intercepting aligned_alloc
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
> * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
> format mismatch between libasan and GCC
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
> * Bug 78028 - ASAN doesn't find memory leak
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
> * Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
> "Unsupported arch"
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
> * Bug 78654 - ubsan can lead to excessive stack usage
> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
> * Bug 60892 - GCC (libsanitizer) 

Re: Killing old dead bugs

[Jonathan Wakely]

On 18 July 2017 at 16:32, Yuri Gribov wrote:
> Jonathan also mentioned something not immediately obvious in IRC:
> logging into BZ with gcc.gnu.org account provides elevated privileges.
> So if you have write access, you should get extra BZ rights for free.

We should document this at https://gcc.gnu.org/bugs/management.html
and maybe also somewhere more visible (I'd forgotten that page even
existed).

Re: Killing old dead bugs

[Yuri Gribov]

On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor  wrote:
> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>
>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:
>>>
>>> On 07/17/2017 02:14 AM, Yuri Gribov wrote:


 Hi Mikhail,

 On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
 wrote:
>
>
> Hi. Yes, bug maintenance is appreciated. See this message and replies
> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .



 Replies in your link suggest to leave a final comment in bugs with
 explanatory suggestion to close them so that maintainers who read
 gcc-bugs list hopefully notice them and act appropriately.
 Unfortunately I found this to _not_ work in practice. Below you can
 see a list of bugs I've investigated (and often bisected) in the past
 weeks - none of them were closed by maintainers (or at least
 commented).

 So I'm afraid we have to conclude that there's no working process to
 close stale bugs in place (which may be one of the reasons of bugcount
 growth).
>>>
>>>
>>>
>>> The informal process that some (most?) of us have been following
>>> is to close them with a comment explaining our rationale.
>>> It's good to fill in the Known to fail/Known to work versions if they
>>> can be determined.  Mentioning the commit that fixed the bug as
>>> you did for the bugs below is ideal.  Adding a test case if one
>>> doesn't exist in the test suite is also very useful, though quite
>>> a bit more work.  In my experience, if a bug is closed that should
>>> stay open, someone usually notices pretty quickly and reopens it,
>>> so I wouldn't be too worried about doing something wrong.
>>
>>
>> Martin,
>>
>> Firstly, thanks for detailed explanation.
>>
>> What to do about bugs originating in upstream packages?  I noticed
>> they sometimes get closed with "RESOLVED MOVED" resolution
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
>> does not happen and they just hang in tracker forever for no good
>> reason.
>>
>> Actually what I tried to emphasize is that it's impossible for a
>> casual commiter (who does not have maintainer access to Bugzilla i.e.
>> rights to close bugs) to contribute to project by cleaning stale bugs,
>> because requests to close them are mostly ignored (because
>> maintainers, obviously, have much more interesting work to do).
>
>
> I take your point.  I didn't realize closing bugs was restricted.
> Given the work you've done on the bugs below (and elsewhere) you
> should be able to close them.  If you aren't and would like to be
> able to, please request it by emailing overse...@gcc.gnu.org ((at
> least I think that's the right way to go about it), or follow up
> here and I'm sure someone with the right karma will make it happen.

Jonathan also mentioned something not immediately obvious in IRC:
logging into BZ with gcc.gnu.org account provides elevated privileges.
So if you have write access, you should get extra BZ rights for free.

>>> The process for managing bugs is in more detail described here:
>>>
>>>   https://gcc.gnu.org/bugs/management.html
>>>
>>> If you think it should be clarified in some way please feel free
>>> to send in a patch.
>>>
>>> Martin
>>>
>>>

 * Bug 41992 - ICE on invalid dereferencing of void *
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
 * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
 underlying type
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
 * Bug 61693 - [asan] is not intercepting aligned_alloc
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
 * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
 format mismatch between libasan and GCC
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
 * Bug 78028 - ASAN doesn't find memory leak
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
 * Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
 "Unsupported arch"
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
 * Bug 78654 - ubsan can lead to excessive stack usage
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
 * Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
 headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
 * Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
 * Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
 * Bug 54123 - inline functions not optimized as well as static inline
 (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)

 -Y

>>>
>

Re: Killing old dead bugs

[Martin Sebor]

On 07/17/2017 02:25 PM, Yuri Gribov wrote:

On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:

On 07/17/2017 02:14 AM, Yuri Gribov wrote:


Hi Mikhail,

On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
wrote:


Hi. Yes, bug maintenance is appreciated. See this message and replies
to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .



Replies in your link suggest to leave a final comment in bugs with
explanatory suggestion to close them so that maintainers who read
gcc-bugs list hopefully notice them and act appropriately.
Unfortunately I found this to _not_ work in practice. Below you can
see a list of bugs I've investigated (and often bisected) in the past
weeks - none of them were closed by maintainers (or at least
commented).

So I'm afraid we have to conclude that there's no working process to
close stale bugs in place (which may be one of the reasons of bugcount
growth).



The informal process that some (most?) of us have been following
is to close them with a comment explaining our rationale.
It's good to fill in the Known to fail/Known to work versions if they
can be determined.  Mentioning the commit that fixed the bug as
you did for the bugs below is ideal.  Adding a test case if one
doesn't exist in the test suite is also very useful, though quite
a bit more work.  In my experience, if a bug is closed that should
stay open, someone usually notices pretty quickly and reopens it,
so I wouldn't be too worried about doing something wrong.


Martin,

Firstly, thanks for detailed explanation.

What to do about bugs originating in upstream packages?  I noticed
they sometimes get closed with "RESOLVED MOVED" resolution
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
does not happen and they just hang in tracker forever for no good
reason.

Actually what I tried to emphasize is that it's impossible for a
casual commiter (who does not have maintainer access to Bugzilla i.e.
rights to close bugs) to contribute to project by cleaning stale bugs,
because requests to close them are mostly ignored (because
maintainers, obviously, have much more interesting work to do).


I take your point.  I didn't realize closing bugs was restricted.
Given the work you've done on the bugs below (and elsewhere) you
should be able to close them.  If you aren't and would like to be
able to, please request it by emailing overse...@gcc.gnu.org ((at
least I think that's the right way to go about it), or follow up
here and I'm sure someone with the right karma will make it happen.

Martin




The process for managing bugs is in more detail described here:

  https://gcc.gnu.org/bugs/management.html

If you think it should be clarified in some way please feel free
to send in a patch.

Martin




* Bug 41992 - ICE on invalid dereferencing of void *
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
* Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
underlying type
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
* Bug 61693 - [asan] is not intercepting aligned_alloc
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
* Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
format mismatch between libasan and GCC
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
* Bug 78028 - ASAN doesn't find memory leak
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
* Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
"Unsupported arch"
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
* Bug 78654 - ubsan can lead to excessive stack usage
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
* Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
* Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
* Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
* Bug 54123 - inline functions not optimized as well as static inline
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)

-Y

Re: Killing old dead bugs

[Jonathan Wakely]

On 17 July 2017 at 21:25, Yuri Gribov wrote:
> What to do about bugs originating in upstream packages?  I noticed
> they sometimes get closed with "RESOLVED MOVED" resolution
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
> does not happen and they just hang in tracker forever for no good
> reason.
>
> Actually what I tried to emphasize is that it's impossible for a
> casual commiter (who does not have maintainer access to Bugzilla i.e.
> rights to close bugs) to contribute to project by cleaning stale bugs,
> because requests to close them are mostly ignored (because
> maintainers, obviously, have much more interesting work to do).

Even if the bug remains open until a maintainer happens to look at it
again, the information that it's fixed in a current release is still
useful to add.

So I'd encourage you to still add such information, you're not wasting
your time.

Re: Killing old dead bugs

[Jeff Law]

On 07/17/2017 10:33 PM, NightStrike wrote:
> On Mon, Jul 17, 2017 at 11:23 AM, Martin Sebor  wrote:
>> you did for the bugs below is ideal.  Adding a test case if one
>> doesn't exist in the test suite is also very useful, though quite
>> a bit more work.
> 
> Isn't a testcase always required?
Required?  No.  Preferred?  Yes.

jeff

Re: Killing old dead bugs

[NightStrike]

On Mon, Jul 17, 2017 at 11:23 AM, Martin Sebor  wrote:
> you did for the bugs below is ideal.  Adding a test case if one
> doesn't exist in the test suite is also very useful, though quite
> a bit more work.

Isn't a testcase always required?

Re: Killing old dead bugs

[Yuri Gribov]

On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor  wrote:
> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>
>> Hi Mikhail,
>>
>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev 
>> wrote:
>>>
>>> Hi. Yes, bug maintenance is appreciated. See this message and replies
>>> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
>>
>>
>> Replies in your link suggest to leave a final comment in bugs with
>> explanatory suggestion to close them so that maintainers who read
>> gcc-bugs list hopefully notice them and act appropriately.
>> Unfortunately I found this to _not_ work in practice. Below you can
>> see a list of bugs I've investigated (and often bisected) in the past
>> weeks - none of them were closed by maintainers (or at least
>> commented).
>>
>> So I'm afraid we have to conclude that there's no working process to
>> close stale bugs in place (which may be one of the reasons of bugcount
>> growth).
>
>
> The informal process that some (most?) of us have been following
> is to close them with a comment explaining our rationale.
> It's good to fill in the Known to fail/Known to work versions if they
> can be determined.  Mentioning the commit that fixed the bug as
> you did for the bugs below is ideal.  Adding a test case if one
> doesn't exist in the test suite is also very useful, though quite
> a bit more work.  In my experience, if a bug is closed that should
> stay open, someone usually notices pretty quickly and reopens it,
> so I wouldn't be too worried about doing something wrong.

Martin,

Firstly, thanks for detailed explanation.

What to do about bugs originating in upstream packages?  I noticed
they sometimes get closed with "RESOLVED MOVED" resolution
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58841) but often this
does not happen and they just hang in tracker forever for no good
reason.

Actually what I tried to emphasize is that it's impossible for a
casual commiter (who does not have maintainer access to Bugzilla i.e.
rights to close bugs) to contribute to project by cleaning stale bugs,
because requests to close them are mostly ignored (because
maintainers, obviously, have much more interesting work to do).

> The process for managing bugs is in more detail described here:
>
>   https://gcc.gnu.org/bugs/management.html
>
> If you think it should be clarified in some way please feel free
> to send in a patch.
>
> Martin
>
>
>>
>> * Bug 41992 - ICE on invalid dereferencing of void *
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
>> * Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
>> underlying type
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
>> * Bug 61693 - [asan] is not intercepting aligned_alloc
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
>> * Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
>> format mismatch between libasan and GCC
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
>> * Bug 78028 - ASAN doesn't find memory leak
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
>> * Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
>> "Unsupported arch"
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
>> * Bug 78654 - ubsan can lead to excessive stack usage
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
>> * Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
>> headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
>> * Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
>> * Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
>> * Bug 54123 - inline functions not optimized as well as static inline
>> (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)
>>
>> -Y
>>
>

Re: Killing old dead bugs

[Martin Sebor]

On 07/17/2017 02:14 AM, Yuri Gribov wrote:

Hi Mikhail,

On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev  wrote:

Hi. Yes, bug maintenance is appreciated. See this message and replies
to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .


Replies in your link suggest to leave a final comment in bugs with
explanatory suggestion to close them so that maintainers who read
gcc-bugs list hopefully notice them and act appropriately.
Unfortunately I found this to _not_ work in practice. Below you can
see a list of bugs I've investigated (and often bisected) in the past
weeks - none of them were closed by maintainers (or at least
commented).

So I'm afraid we have to conclude that there's no working process to
close stale bugs in place (which may be one of the reasons of bugcount
growth).


The informal process that some (most?) of us have been following
is to close them with a comment explaining our rationale.  It's
good to fill in the Known to fail/Known to work versions if they
can be determined.  Mentioning the commit that fixed the bug as
you did for the bugs below is ideal.  Adding a test case if one
doesn't exist in the test suite is also very useful, though quite
a bit more work.  In my experience, if a bug is closed that should
stay open, someone usually notices pretty quickly and reopens it,
so I wouldn't be too worried about doing something wrong.

The process for managing bugs is in more detail described here:

  https://gcc.gnu.org/bugs/management.html

If you think it should be clarified in some way please feel free
to send in a patch.

Martin



* Bug 41992 - ICE on invalid dereferencing of void *
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
* Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
underlying type
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
* Bug 61693 - [asan] is not intercepting aligned_alloc
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
* Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
format mismatch between libasan and GCC
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
* Bug 78028 - ASAN doesn't find memory leak
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
* Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
"Unsupported arch"
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
* Bug 78654 - ubsan can lead to excessive stack usage
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
* Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
* Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
* Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
* Bug 54123 - inline functions not optimized as well as static inline
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)

-Y

Re: Killing old dead bugs

[Yuri Gribov]

Hi Mikhail,

On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev  wrote:
> Hi. Yes, bug maintenance is appreciated. See this message and replies
> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .

Replies in your link suggest to leave a final comment in bugs with
explanatory suggestion to close them so that maintainers who read
gcc-bugs list hopefully notice them and act appropriately.
Unfortunately I found this to _not_ work in practice. Below you can
see a list of bugs I've investigated (and often bisected) in the past
weeks - none of them were closed by maintainers (or at least
commented).

So I'm afraid we have to conclude that there's no working process to
close stale bugs in place (which may be one of the reasons of bugcount
growth).

* Bug 41992 - ICE on invalid dereferencing of void *
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00860.html)
* Bug 63245 - renderMemorySnippet shouldn't show more bytes than the
underlying type
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00645.html)
* Bug 61693 - [asan] is not intercepting aligned_alloc
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00643.html)
* Bug 61771 - Test failures in ASan testsuite on ARM Linux due to FP
format mismatch between libasan and GCC
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00646.html)
* Bug 78028 - ASAN doesn't find memory leak
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00653.html)
* Bug 55316 - gcc/libsanitizer/asan/asan_linux.cc:70:3: error: #error
"Unsupported arch"
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00636.html)
* Bug 78654 - ubsan can lead to excessive stack usage
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00640.html)
* Bug 60892 - GCC (libsanitizer) fails to build with Linux 2.6.21
headers (https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00649.html)
* Bug 61995 - gcc 4.9.1 fails to compile with error in libsanitizer
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00648.html)
* Bug 80027 - ASAN breaks DT_RPATH $ORIGIN in dlopen()
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg00787.html)
* Bug 54123 - inline functions not optimized as well as static inline
(https://gcc.gnu.org/ml/gcc-bugs/2017-07/msg01321.html)

-Y

Re: Killing old dead bugs

[Jeff Law]

On 07/02/2017 11:08 AM, Yuri Gribov wrote:
> Hi all,
> 
> What do I need to do to close an old bug which does not repro with
> modern GCC and reporter does not care anymore (e.g.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528)? Also, is there
> some general policy about closing old bugs?
Ideally you'd bisect the tree to figure out what change causes the bug
not to reproduce anymore -- that way you can make an educated guess
whether or not the bug was fixed or just went latent.

Sometimes that can be skipped with sufficient knowledge of the bug.

The fact that the reporter doesn't care anymore is useful, but what's
far more important is whether or not the bug is likely someone else
would run into.

>From reviewing the BZ, the core request is for ifunc capabilities to be
exposed as an attribute.  THat's been around for a long time.  I think
the core issue was Agner had a much too old binutils (2.20-ish).

jeff

Re: Killing old dead bugs

[Mikhail Maltsev]

Hi. Yes, bug maintenance is appreciated. See this message and replies
to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
I'm not sure that there is a documented policy, but I might be wrong.

-- 
Regards,
   Mikhail Maltsev

Killing old dead bugs

[Yuri Gribov]

Hi all,

What do I need to do to close an old bug which does not repro with
modern GCC and reporter does not care anymore (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528)? Also, is there
some general policy about closing old bugs?

-Y