Re: when (not) use bugzilla for GCC?

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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} ***