when (not) use bugzilla for GCC?

when (not) use bugzilla for GCC?

[Basile STARYNKEVITCH]

Hello All,


Please accept my apologies if the questions below are too naive!

I have several questions about bugzilla and GCC. I am not very familiar 
with bugzilla, and I am not familiar with the configuration of GCC 
bugzilla in particular.

I cannot understand when should I use or not bugzilla. More precisely, I 
have several examples of "bugs" but I didn't use bugzilla for them


1. I regularily test the latest gcc trunk with -flto on a medium sized 
program. And it always crashes, with a sisegv fatal error. My feeling is 
that it should not crash that way (at least, I would prefer a message 
such as not enough memory to compile with -flto). Should I report that 
as a bug on bugzilla? I am not able at all to reduce that example to 
something smaller.

For the record, that program is Jacques Pitrat's MALICE system 
http://pagesperso-orange.fr/jacques.pitrat/MALICE.html
about 370KLOC  (less than 14Mbytes total) of C files (all 2947 C files 
are generated and usually short, MALICE is bootstrapped that is 
generates all its C code; the C code is not understandable!). I would 
imagine that it is not big enough to reach the limits of my 8Gb desktop!


Should I report that as a bug?


2. a couple of weeks ago, I submitted a patch regarding gengtype for 
plugins (the patch was greatly improved by Rafael Espindola 
espindola@google.com) and the patch did correct a bug. 
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00379.html
but I never bothered registering it (since making the initial patch was 
easier than reporting a bug). This is also the case of 
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00809.html
(fatal error when failing to register a pass)


3. On the MELT branch, I regularily find bugs & correct them, and it did 
happen that someone registered a MELT bug on the bugzilla; I did correct 
it but AFAIR was not permitted to close the bug. Sometimes I am sad of 
not being able to report MELT bugs on bugzilla and to close them when I 
feel I have covered them.





My current intuition is that bugzilla might be reserved for bugs of the 
trunk mostly  for which a small testcase is available, and which is a 
bug affecting many users (this is not the case of all the bugs 
mentionned above).

So when should I use bugzilla? I am a bit "scared" to use it!


I hope I am not offending anyone, and I admit that I am not familiar 
with bugzilla in general and its GCC policy & setting in particular.

I also am guessing that bugzilla is less important for the GCC community 
than in some other big free software communities. It does not seem to be 
a major communication channel.

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: when (not) use bugzilla for GCC?

[Joseph S. Myers]

On Sun, 25 Oct 2009, Basile STARYNKEVITCH wrote:

> I cannot understand when should I use or not bugzilla. More precisely, I have
> several examples of "bugs" but I didn't use bugzilla for them

If something is a bug in trunk then you should report it, but do not 
submit reports that do not contain sufficient information to convince the 
reader that there is a bug.  For example, a report should not rely on 
source files on a third-party website, installed system headers, or on the 
hypothetical correctness of some unreduced code (if you are claiming wrong 
code, reduce it to a single function or a minimal set of functions).

For development branches, it's up to the branch maintainer.  If they wish 
to use Bugzilla for bugs in them, they should add appropriate versions so 
the bugs can be accurately reported as bugs against the branch.

> 2. a couple of weeks ago, I submitted a patch regarding gengtype for plugins
> (the patch was greatly improved by Rafael Espindola espindola@google.com) and
> the patch did correct a bug.
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00379.html
> but I never bothered registering it (since making the initial patch was easier
> than reporting a bug). This is also the case of
> http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00809.html
> (fatal error when failing to register a pass)

If you want a regression to be tracked as such, it needs a Bugzilla entry, 
even if there is also a patch submission.  Any bug with a patch can be 
filed if desired, but do not use Bugzilla as a patch submission mechanism; 
send patches to gcc-patches and use the "patch URL" field in the bugs.  
Ping patches on gcc-patches weekly until they are reviewed.  If you attach 
a patch in progress to Bugzilla, make clear that it is a work in progress 
and that a final version will be submitted to gcc-patches.

If you stop working on a bug, do not leave yourself assigned to it; 
ASSIGNED should only be for bugs where you are genuinely working on them.

> 3. On the MELT branch, I regularily find bugs & correct them, and it did
> happen that someone registered a MELT bug on the bugzilla; I did correct it
> but AFAIR was not permitted to close the bug. Sometimes I am sad of not being
> able to report MELT bugs on bugzilla and to close them when I feel I have
> covered them.

Log in to Bugzilla with your gcc.gnu.org address to get access to close 
bugs, add versions and milestones, etc.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: when (not) use bugzilla for GCC?

[Basile STARYNKEVITCH]

Joseph S. Myers wrote:
> On Sun, 25 Oct 2009, Basile STARYNKEVITCH wrote:
> 
>> I cannot understand when should I use or not bugzilla. More precisely, I have
>> several examples of "bugs" but I didn't use bugzilla for them

A big thanks to your reply. However, you did not answer to my example 1. 
J.Pitrat's MALICE system on 
http://pagesperso-orange.fr/jacques.pitrat/MALICE.html

The point is that I cannot reduce that example, because it is almost 
3000 usually small files of generated C (totalizing 370865 lines or 
13862311 bytes) like eg its TRIPLETS2.c file which contains

#include "dx.h"
void TRIPLETS2(void )
/*generated C source file TRIPLETS2.c of the CAIA system - Copyright 
Jacques  Pitrat 2009 - GPLv3 license. See COPYING3*/
{int N;
int NNNE;
int WZ1,WZ2,WZ3,WZ4,WZ5;
int jvj;
jvj=v[0];
v[0]+=11;
x[jvj+1]=26199;z[jvj+1]=(-100);
if(v[0]>99700) (*f[6])();
if(v[90]==2441&&v[97]==0) {
(*f[4])();x[jvj+1]=incon;v[0]=jvj;return;
}
N=pile[v[22]];NNNE=pile[v[22]+1];v[22]+=2;
WZ5=v[22]+5;WZ4=v[22]+4;WZ3=v[22]+3;WZ2=v[22]+2;WZ1=v[22]+1;
x[jvj+2]=0;z[jvj+2]=0;
pile[v[22]]=100;pile[WZ1]=20;pile[WZ2]=101;pile[WZ3]=29;pile[WZ4]=jvj+4;
(*f[175])();     /*QUADRI2(100,20,101,29,jvj+4)*/
pile[WZ1]=41;pile[WZ2]=130;pile[WZ3]=N;pile[WZ4]=jvj+8;
(*f[256])();     /*QUADRI7(100,41,130,N,jvj+8)*/
pile[WZ1]=21;pile[WZ2]=140;pile[WZ3]=(-632);pile[WZ4]=jvj+9;
(*f[255])();     /*QUADRI6(100,21,140,(-632),jvj+9)*/
pile[WZ1]=41;pile[WZ2]=130;pile[WZ3]=0;pile[WZ4]=jvj+11;
(*f[256])();     /*QUADRI7(100,41,130,0,jvj+11)*/
pile[v[22]]=jvj+9;pile[WZ1]=111;pile[WZ2]=jvj+10;
(*f[68])();     /*TRI4(jvj+9,111,jvj+10)*/
pile[v[22]]=100;pile[WZ1]=484;pile[WZ2]=102;pile[WZ3]=jvj+11;pile[WZ4]=jvj+10;pile[WZ5]=jvj+6;
(*f[254])();     /*QUADRI5(100,484,102,jvj+11,jvj+10,jvj+6)*/
pile[v[22]]=jvj+4;pile[WZ1]=111;pile[WZ2]=jvj+5;
(*f[68])();     /*TRI4(jvj+4,111,jvj+5)*/
pile[v[22]]=jvj+5;pile[WZ1]=jvj+6;pile[WZ2]=103;pile[WZ3]=jvj+7;
(*f[58])();     /*TRI2(jvj+5,jvj+6,103,jvj+7)*/
pile[v[22]]=100;pile[WZ1]=22;pile[WZ2]=102;pile[WZ3]=jvj+8;pile[WZ4]=jvj+7;pile[WZ5]=jvj+3;
(*f[254])();     /*QUADRI5(100,22,102,jvj+8,jvj+7,jvj+3)*/
pile[v[22]]=jvj+2;pile[WZ1]=jvj+3;
(*f[503])();     /*PLUB2(jvj+2,jvj+3)*/
x[NNNE]=x[jvj+2];z[NNNE]=z[jvj+2];
l1:x[jvj+1]=incon;v[0]=jvj;v[22]-=2;return;
}

Every such C file starts with #include "dx.h" and dx.h itself includes 
some system headers <stdio.h> <ctype.h> <signal.h> <dlfcn.h> <time.h> 
<unistd.h> <sys/mman.h> <errno.h> <stdlib.h>
and declare nearly 3000 functions like
void TRANSFORMC0(void ); and also a dozen arrays like int sk[201][401];
int tu[600000]; short int ts[600000];




As you can see, the C source file above is not human-understandable. It 
is generated. And there are almost three thousand files like this.
I am definitely not able to reduce that to a smaller example.

For what it is worth, MALICE is a reflexive constraint solving system. 
It manages it own stacks. I think that v[22] is used as a "top of 
argument stack" index into pile[] used as its argument stack, and I was 
hoping that with -flto -O2, gcc could perhaps share a little better that 
index.

Are you suggesting me to upload to bugzilla the nearly 3000 preprocessed 
forms of the files? I could do that, but the *.i files totalize more 
than one gigabyte. A bzip2 compressed tar archive of them is almost 
80Mbytes.

I was trying to compile that stuff with
    gcc-trunk -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice
and there is a sigsegv in the lto2 process. I don't even know how to 
debug that (just how to start in the gdb debugger the lto process with 
the correct invocation).

I agree that this example is perhaps contrived or at least unusual, but 
LTO bugs probably all involve several files (that what is LTO about), 
and there are situations where reducing an example to something 
manageable is not easy. I was with the intuition that this MALICE 
example should be compilable by LTO. It is not that big by today's 
standards (it is at least 10 times smaller than GCC). And the sigsegv 
does not occur when memory is rare (I have 8Gb RAM and not all of it is 
used when lto crashes.).

> 
>> 3. On the MELT branch, I regularily find bugs & correct them, and it did
>> happen that someone registered a MELT bug on the bugzilla; I did correct it
>> but AFAIR was not permitted to close the bug. Sometimes I am sad of not being
>> able to report MELT bugs on bugzilla and to close them when I feel I have
>> covered them.
> 
> Log in to Bugzilla with your gcc.gnu.org address to get access to close 
> bugs, add versions and milestones, etc.

Did I understand correctly that GCC bugzilla treats magically the 
*@gcc.gnu.org email adresses matching accounts usable for SVN write 
access? This is great news!

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: when (not) use bugzilla for GCC?

[Ian Lance Taylor]

Basile STARYNKEVITCH <basile@starynkevitch.net> writes:

> Are you suggesting me to upload to bugzilla the nearly 3000
> preprocessed forms of the files? I could do that, but the *.i files
> totalize more than one gigabyte. A bzip2 compressed tar archive of
> them is almost 80Mbytes.

That is a difficulty, but without a self-contained test case it's
pretty hard to fix the bug.  You can try reporting the bug with a URL
for where to download the sources.  Since LTO is fairly new a
maintainer may be willing to download them and try it.  Otherwise, go
ahead and upload that 80M tar ball.  gcc.gnu.org will cope.


> Did I understand correctly that GCC bugzilla treats magically the
> *@gcc.gnu.org email adresses matching accounts usable for SVN write
> access? This is great news!

Yes, that is how it works.

Ian

Re: when (not) use bugzilla for GCC?

[Richard Guenther]

On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com> wrote:
> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>
>> Are you suggesting me to upload to bugzilla the nearly 3000
>> preprocessed forms of the files? I could do that, but the *.i files
>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>> them is almost 80Mbytes.
>
> That is a difficulty, but without a self-contained test case it's
> pretty hard to fix the bug.  You can try reporting the bug with a URL
> for where to download the sources.  Since LTO is fairly new a
> maintainer may be willing to download them and try it.  Otherwise, go
> ahead and upload that 80M tar ball.  gcc.gnu.org will cope.

Please don't.  Bi-sect the list of object files by adding -r -nostdlib
to the link line.  This should result in a two or three file testcase.
Either attach those or reduce them with delta.

Richard.

Re: when (not) use bugzilla for GCC?

[Basile STARYNKEVITCH]

Richard Guenther wrote:
> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com> wrote:
>> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>>
>>> Are you suggesting me to upload to bugzilla the nearly 3000
>>> preprocessed forms of the files? I could do that, but the *.i files
>>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>> them is almost 80Mbytes.
>> That is a difficulty, but without a self-contained test case it's
>> pretty hard to fix the bug.  You can try reporting the bug with a URL
>> for where to download the sources.  Since LTO is fairly new a
>> maintainer may be willing to download them and try it.  Otherwise, go
>> ahead and upload that 80M tar ball.  gcc.gnu.org will cope.
> 
> Please don't.  Bi-sect the list of object files by adding -r -nostdlib
> to the link line.  This should result in a two or three file testcase.
> Either attach those or reduce them with delta.


I am not sure to understand what that means technically.

The sisegv is gotten by running

     gcc -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice-lto

where the [A-Z]*.c file glob pattern expand to nearly 3000 files. 
Exactly those from 
http://pagesperso-orange.fr/jacques.pitrat/malice-2009.tar.bz2

What command to you suggest me to run? How will I find the faulty files...


Regards.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: when (not) use bugzilla for GCC?

[Richard Guenther]

On Mon, Oct 26, 2009 at 3:39 PM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
> Richard Guenther wrote:
>>
>> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>
>>> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>>>
>>>> Are you suggesting me to upload to bugzilla the nearly 3000
>>>> preprocessed forms of the files? I could do that, but the *.i files
>>>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>>> them is almost 80Mbytes.
>>>
>>> That is a difficulty, but without a self-contained test case it's
>>> pretty hard to fix the bug.  You can try reporting the bug with a URL
>>> for where to download the sources.  Since LTO is fairly new a
>>> maintainer may be willing to download them and try it.  Otherwise, go
>>> ahead and upload that 80M tar ball.  gcc.gnu.org will cope.
>>
>> Please don't.  Bi-sect the list of object files by adding -r -nostdlib
>> to the link line.  This should result in a two or three file testcase.
>> Either attach those or reduce them with delta.
>
>
> I am not sure to understand what that means technically.
>
> The sisegv is gotten by running
>
>    gcc -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice-lto
>
> where the [A-Z]*.c file glob pattern expand to nearly 3000 files. Exactly
> those from http://pagesperso-orange.fr/jacques.pitrat/malice-2009.tar.bz2
>
> What command to you suggest me to run? How will I find the faulty files...

See the LTO section in http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction

Richard.

Re: when (not) use bugzilla for GCC?

[Basile STARYNKEVITCH]

Basile STARYNKEVITCH wrote:
> Richard Guenther wrote:
>> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor <iant@google.com> 
>> wrote:
>>> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>>>
>>>> Are you suggesting me to upload to bugzilla the nearly 3000
>>>> preprocessed forms of the files? I could do that, but the *.i files
>>>> totalize more than one gigabyte. A bzip2 compressed tar archive of
>>>> them is almost 80Mbytes.


I actually found that the bug is triggered by any gcc -flto -O2 
compilation of a lot of files.

I submitted PRµ41858 with a tiny C-source file generator. So the example 
main.c in the bugzilla is tiny, but able to generate a lot of source code.

I hope that this helps.

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: when (not) use bugzilla for GCC?

[Basile STARYNKEVITCH]

Ian Lance Taylor wrote:
> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
> 
>> Did I understand correctly that GCC bugzilla treats magically the
>> *@gcc.gnu.org email adresses matching accounts usable for SVN write
>> access? This is great news!
> 
> Yes, that is how it works.


May I respectfully suggest to the person maintaining the bugzilla a 
notice in the login page saying something like:

GCC maintainers having write after approval (or better) access to the 
GCC trunk should preferably login with their XXXXX@gcc.gnu.org email

Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: when (not) use bugzilla for GCC?

[Ian Lance Taylor]

Basile STARYNKEVITCH <basile@starynkevitch.net> writes:

> May I respectfully suggest to the person maintaining the bugzilla a
> notice in the login page saying something like:
>
> GCC maintainers having write after approval (or better) access to the
> GCC trunk should preferably login with their XXXXX@gcc.gnu.org email

Good idea, but nobody maintains bugzilla these days, at least beyond
the bare minimum of taking a look if something breaks.  If anybody
wants to tackle this and knows what to do, let me know.

Ian