GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Karel Gardas]

Hello,

I have just build MICO 2.3.11's ORB core directory (http://www.mico.org)
with both compilers from subject with -time -O0 -Wall -DPIC -fPIC -c
options and the comparison table looks:

[1] File
[2] GCC 3.3.2
[3] GCC 3.4.0 20040114
[4] Delta %

[1]		[2]	[3]	[4]
os-unix.cc	4.91	5.33	-7.88
dii.cc		17.45	18.58	-6.08
typecode.cc	10.2	10.51	-2.95
any.cc		7.51	7.65	-1.83
codec.cc	6.57	6.68	-1.65
buffer.cc	4.13	3.94	4.82
context.cc	4.22	4.15	1.69
except.cc	5.29	5.67	-6.7
dispatch.cc	5.23	5.62	-6.94
string.cc	4.09	3.95	3.54
object.cc	5.62	5.81	-3.27
address.cc	5.73	6.05	-5.29
ior.cc		16.98	18.27	-7.06
orb.cc		22.46	23.08	-2.69
boa.cc		10.32	10.98	-6.01
dsi.cc		14.83	16.01	-7.37
transport.cc	5.01	5.25	-4.57
t..port/tcp.cc	4.73	5.17	-8.51
t..port/udp.cc	4.73	5.24	-9.73
t..port/unix.cc	4.79	5.19	-7.71
iop.cc		20.54	22.42	-8.39
util.cc		6.5	7.02	-7.41
basic_seq.cc	4.34	4.32	0.46
fast_array.cc	4.7	4.67	0.64
ssl.cc		13.66	15.15	-9.83
fixed.cc	4.43	4.34	2.07
intercept.cc	14.66	15.75	-6.92
codeset.cc	6.44	6.91	-6.8
queue.cc	5.14	5.51	-6.72
static.cc	25.59	26.58	-3.72
current.cc	13.19	14.84	-11.12
policy_impl.cc	17.3	18.8	-7.98
service_info.cc	13.18	14.63	-9.91
ioptypes.cc	15.01	16.51	-9.09
ssliop.cc	13.45	14.74	-8.75
value.cc	15.72	16.66	-5.64
valuetype.cc	14.31	15.88	-9.89
v..type_impl.cc	17.02	18.64	-8.69
dynany_impl.cc	11.02	11.74	-6.13
policy2.cc	13.37	14.77	-9.48
tckind.cc	13.17	14.87	-11.43
orb_excepts.cc	13.26	14.89	-10.95
policy.cc	13.29	14.52	-8.47
poa.cc		17.16	19.07	-10.02
poa_base.cc	14.43	15.95	-9.53
poa_impl.cc	22.55	23.81	-5.29
dynany.cc	14.52	15.97	-9.08
uni_base64.cc	0.1	0.12	-16.67
uni_unicode.cc	0.17	0.21	-19.05
uni_fromuni.cc	0.35	0.41	-14.63
uni_touni.cc	0.38	0.47	-19.15
except2.cc	7.06	7.47	-5.49
pi.cc		15.61	17.53	-10.95
pi_impl.cc	23.57	24.79	-4.92
typecode_seq.cc	13.58	14.99	-9.41
timebase.cc	13.24	14.44	-8.31
ir.cc		59.49	53.89	10.39
ir_base.cc	16.19	17.64	-8.22
imr.cc		19.07	23.93	-20.31
mtdebug.cc	4.6	4.61	-0.22

Sum		696.16	742.59	-6.25


So as you can see, we have about six percents slowdown with the GCC 3.4.0
in comparison with GCC 3.3.2.

In case anybody is interested, I would be happy to provide him/her with
some interesting preprocessed files for more detailed testing.

Thanks for your work on GCC!

Karel

PS: GCC 3.4.0 was configured with:
thinkpad:~$ c++ -v
Reading specs from
/home/karel/usr/local/gcc-main/lib/gcc/i686-pc-linux-gnu/3.4.0/specs
Configured with: ../gcc-main/configure
--prefix=/home/karel/usr/local/gcc-main --enable-shared --enable-threads
--enable-languages=c++ --disable-checking --enable-__cxa_atexit
Thread model: posix
gcc version 3.4.0 20040114 (experimental)


GCC 3.3.2 was configured with:
thinkpad:~$ c++ -v
Reading specs from
/home/karel/usr/local/gcc3.3.2/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: ../gcc-3_3-branch/configure
--prefix=/home/karel/usr/local/gcc3.3.2 --enable-shared --enable-threads
--enable-languages=c++ --disable-checking --enable-__cxa_atexit
Thread model: posix
gcc version 3.3.2
thinkpad:/mnt/karel/sl3-for-atlas/demo/security/atlas-sl3$

PPS: Are you also interested in optimized (-O2) build?
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Eric Christopher]

> 
> PPS: Are you also interested in optimized (-O2) build?

Probably more than the other :)

Thanks for the mail though. Perhaps a bug report into bugzilla with a
url on where someone can download the .ii files would be best :)

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Karel Gardas]

On Mon, 19 Jan 2004, Eric Christopher wrote:

>
> >
> > PPS: Are you also interested in optimized (-O2) build?
>
> Probably more than the other :)

OK, I have thought that the -O0 -g (perhaps) build is the most important
from compile-time performance view, as it is probably used for
development...

> Thanks for the mail though. Perhaps a bug report into bugzilla with a
> url on where someone can download the .ii files would be best :)

I will try to provide something this week.

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Eric Christopher]

> OK, I have thought that the -O0 -g (perhaps) build is the most important
> from compile-time performance view, as it is probably used for
> development...
> 

Don't get me wrong, both are useful. For some reason my mind is hitting
that we're doing more stuff up front to allow for better optimization
later though.

> > Thanks for the mail though. Perhaps a bug report into bugzilla with a
> > url on where someone can download the .ii files would be best :)
> 
> I will try to provide something this week.

Thanks.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Gerald Pfeifer]

On Mon, 19 Jan 2004, Karel Gardas wrote:
> OK, I have thought that the -O0 -g (perhaps) build is the most important
> from compile-time performance view, as it is probably used for
> development...

Just as an example, in DLV (origin of PR8361) I switched to -O1 years
ago because that was _faster_ than -O0 at that time, debugging was still
okay, and test runs with the generated binary were much faster.

-O0 really is not too useful in some contexts.

Gerald
-- 
Gerald Pfeifer <gp@suse.de>    Technical Project Manager, SUSE Linux AG

Re: GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Karel Gardas]

On Mon, 19 Jan 2004, Gerald Pfeifer wrote:

> On Mon, 19 Jan 2004, Karel Gardas wrote:
> > OK, I have thought that the -O0 -g (perhaps) build is the most important
> > from compile-time performance view, as it is probably used for
> > development...
>
> Just as an example, in DLV (origin of PR8361) I switched to -O1 years
> ago because that was _faster_ than -O0 at that time, debugging was still
> okay, and test runs with the generated binary were much faster.
>
> -O0 really is not too useful in some contexts.

OK, I will try to add -O1, -O2 and -O3 to the table. Then I will search
for biggest slowdowns in different files (hand-written/machine generated)
and create bugreport for bugzilla.

Thanks for all your suggestions,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

[UPDATED] GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Karel Gardas]

On Mon, 19 Jan 2004, Karel Gardas wrote:

>
> Hello,
>
> I have just build MICO 2.3.11's ORB core directory (http://www.mico.org)
> with both compilers from subject with -time -O0 -Wall -DPIC -fPIC -c
> options and the comparison table looks:
>

Here is updated table. I have added -O1, -O2, -O3 and -Os as per your kind
request. The results are IMHO interesting, so please read small conclusion
below.


File		332-O0	340-0O	Delta %	332-O1	340-O1	Delta %	332-O2	340-O2	Delta % 332-O3	340-O3	Delta %	332-Os	340-Os	Delta %

os-unix.cc	4.91	5.33	-7.88	5.16	5.57	-7.36	5.44	5.73	-5.06	5.38	5.79	-7.08	5.38	5.65	-4.78
dii.cc		17.45	18.58	-6.08	18.66	20.79	-10.25	21.03	23.09	-8.92	21.16	23.57	-10.22	20.94	23.12	-9.43
typecode.cc	10.2	10.51	-2.95	19.62	14.12	38.95	25.77	35.16	-26.71	25.98	36.2	-28.23	26.36	34.82	-24.3
any.cc		7.51	7.65	-1.83	10.86	10.72	1.31	13.72	13.8	-0.58	14	14.22	-1.55	13.61	13.44	1.26
codec.cc	6.57	6.68	-1.65	7.73	8.51	-9.17	9.32	10.25	-9.07	9.83	11.22	-12.39	9.11	9.77	-6.76
buffer.cc	4.13	3.94	4.82	4.29	4.26	0.7	4.43	4.36	1.61	4.46	4.53	-1.55	4.52	4.17	8.39
context.cc	4.22	4.15	1.69	4.58	4.56	0.44	4.95	4.77	3.77	5.02	5	0.4	4.83	4.69	2.99
except.cc	5.29	5.67	-6.7	5.69	6.32	-9.97	6.69	7.03	-4.84	6.86	7.57	-9.38	6.52	6.81	-4.26
dispatch.cc	5.23	5.62	-6.94	5.64	6.23	-9.47	5.9	6.19	-4.68	5.9	6.36	-7.23	5.92	6.16	-3.9
string.cc	4.09	3.95	3.54	4.21	4.21	0	4.29	4.07	5.41	4.39	4.25	3.29	4.31	4.08	5.64
object.cc	5.62	5.81	-3.27	6.74	6.69	0.75	7.5	7.92	-5.3	7.66	8.32	-7.93	7.35	7.75	-5.16
address.cc	5.73	6.05	-5.29	6.69	7.49	-10.68	7.41	8.06	-8.06	7.52	8.66	-13.16	7.4	7.98	-7.27
ior.cc		16.98	18.27	-7.06	18.63	20.84	-10.6	20.82	22.94	-9.24	21.17	23.61	-10.33	20.89	22.98	-9.09
orb.cc		22.46	23.08	-2.69	34.13	31.75	7.5	43.5	44.84	-2.99	43.93	47.87	-8.23	45.28	45.83	-1.2
boa.cc		10.32	10.98	-6.01	13.74	13.25	3.7	16.45	18.65	-11.8	16.72	19.51	-14.3	19.51	18.69	4.39
dsi.cc		14.83	16.01	-7.37	15.44	16.98	-9.07	16.43	18.49	-11.14	16.54	18.73	-11.69	16.31	18.46	-11.65
transport.cc	5.01	5.25	-4.57	5.05	5.66	-10.78	5.27	5.59	-5.72	5.25	5.69	-7.73	5.27	5.63	-6.39
t..port/tcp.cc	4.73	5.17	-8.51	5.1	5.42	-5.9	5.15	5.56	-7.37	5.34	5.67	-5.82	5.14	5.49	-6.38
t..port/udp.cc	4.73	5.24	-9.73	5.1	5.68	-10.21	5.5	5.84	-5.82	5.47	5.9	-7.29	5.41	5.75	-5.91
t..port/unix.cc	4.79	5.19	-7.71	4.92	5.51	-10.71	5.19	5.46	-4.95	5.19	5.49	-5.46	5.16	5.48	-5.84
iop.cc		20.54	22.42	-8.39	27.33	28.54	-4.24	33.2	35.09	-5.39	34.27	36.39	-5.83	33.07	34.63	-4.5
util.cc		6.5	7.02	-7.41	8.75	8.85	-1.13	10.33	11.44	-9.7	10.73	12.23	-12.26	10.32	11.18	-7.69
basic_seq.cc	4.34	4.32	0.46	4.53	4.65	-2.58	4.66	4.5	3.56	4.78	4.62	3.46	4.65	4.51	3.1
fast_array.cc	4.7	4.67	0.64	4.71	5.32	-11.47	4.81	4.71	2.12	4.94	5.4	-8.52	4.73	4.72	0.21
ssl.cc		13.66	15.15	-9.83	13.6	15.84	-14.14	13.66	15.06	-9.3	13.76	15.09	-8.81	13.95	15.01	-7.06
fixed.cc	4.43	4.34	2.07	4.61	4.75	-2.95	4.97	5.03	-1.19	5.22	6.02	-13.29	7.29	4.87	49.69
intercept.cc	14.66	15.75	-6.92	15.23	16.96	-10.2	16.14	17.73	-8.97	16.06	17.95	-10.53	16.19	17.52	-7.59
codeset.cc	6.44	6.91	-6.8	8.29	8.49	-2.36	10.6	12.01	-11.74	10.88	12.45	-12.61	10.6	11.76	-9.86
queue.cc	5.14	5.51	-6.72	5.48	5.96	-8.05	5.68	5.86	-3.07	5.72	6.11	-6.38	5.75	5.92	-2.87
static.cc	25.59	26.58	-3.72	32.66	32.03	1.97	33.05	36.93	-10.51	32.95	41.05	-19.73	32.77	36.37	-9.9
current.cc	13.19	14.84	-11.12	13.27	14.83	-10.52	13.29	14.41	-7.77	13.29	14.41	-7.77	13.32	14.56	-8.52
policy_impl.cc	17.3	18.8	-7.98	19.27	19.92	-3.26	20.98	24.54	-14.51	20.05	21.75	-7.82	22.34	21.21	5.33
service_info.cc	13.18	14.63	-9.91	13.22	14.61	-9.51	13.26	14.28	-7.14	13.14	14.33	-8.3	13.25	14.23	-6.89
ioptypes.cc	15.01	16.51	-9.09	16.73	18.01	-7.11	17.42	19.43	-10.34	17.8	19.6	-9.18	17.7	21.61	-18.09
ssliop.cc	13.45	14.74	-8.75	13.3	14.91	-10.8	13.56	14.62	-7.25	13.4	14.48	-7.46	13.6	14.55	-6.53
value.cc	15.72	16.66	-5.64	16.37	17.84	-8.24	17.34	18.31	-5.3	17.51	18.55	-5.61	20.03	18.29	9.51
valuetype.cc	14.31	15.88	-9.89	15.51	16.38	-5.31	15.47	16.79	-7.86	15.51	17.44	-11.07	15.6	16.79	-7.09
v..type_impl.cc	17.02	18.64	-8.69	18.67	22.16	-15.75	18.23	23.1	-21.08	18.17	20.07	-9.47	18.29	19.64	-6.87
dynany_impl.cc	11.02	11.74	-6.13	17.49	17.39	0.58	22.75	26.15	-13	26.14	27.06	-3.4	25.38	28.92	-12.24
policy2.cc	13.37	14.77	-9.48	13.36	15	-10.93	13.57	14.81	-8.37	13.77	14.79	-6.9	13.58	14.79	-8.18
tckind.cc	13.17	14.87	-11.43	13.18	14.58	-9.6	13.21	14.38	-8.14	13.05	14.38	-9.25	13.2	14.44	-8.59
orb_excepts.cc	13.26	14.89	-10.95	16.3	15.07	8.16	13.51	14.68	-7.97	13.46	14.65	-8.12	13.54	14.76	-8.27
policy.cc	13.29	14.52	-8.47	13.33	14.78	-9.81	13.55	14.61	-7.26	13.4	14.68	-8.72	13.55	14.55	-6.87
poa.cc		17.16	19.07	-10.02	19.89	24.37	-18.38	22.04	25.03	-11.95	22.23	24.2	-8.14	24.85	26.41	-5.91
poa_base.cc	14.43	15.95	-9.53	15.19	16.7	-9.04	16.08	18.16	-11.45	19.39	18.18	6.66	16.09	17.98	-10.51
poa_impl.cc	22.55	23.81	-5.29	31.34	28.09	11.57	32.68	37.47	-12.78	33.67	36.44	-7.6	36.05	35.23	2.33
dynany.cc	14.52	15.97	-9.08	15.09	16.65	-9.37	15.87	17.8	-10.84	16.04	17.88	-10.29	15.92	17.72	-10.16
uni_base64.cc	0.1	0.12	-16.67	0.16	0.2	-20	0.22	0.27	-18.52	0.23	0.27	-14.81	0.21	1.53	-86.27
uni_unicode.cc	0.17	0.21	-19.05	0.27	0.29	-6.9	0.39	0.45	-13.33	0.41	0.47	-12.77	0.35	1.19	-70.59
uni_fromuni.cc	0.35	0.41	-14.63	0.6	0.61	-1.64	0.98	1.09	-10.09	1.03	1.68	-38.69	1.03	1.16	-11.21
uni_touni.cc	0.38	0.47	-19.15	0.66	0.71	-7.04	1.03	1.19	-13.45	1.02	2.16	-52.78	0.98	1.23	-20.33
except2.cc	7.06	7.47	-5.49	10.23	11.13	-8.09	12.75	13.35	-4.49	13.2	14.06	-6.12	12.74	13.21	-3.56
pi.cc		15.61	17.53	-10.95	16.79	18.53	-9.39	18.23	19.46	-6.32	21.28	19.58	8.68	18.03	19.36	-6.87
pi_impl.cc	23.57	24.79	-4.92	32.09	31.69	1.26	36.58	39.06	-6.35	34.56	38.13	-9.36	36.92	39.85	-7.35
typecode_seq.cc	13.58	14.99	-9.41	13.87	15.27	-9.17	13.9	15.15	-8.25	14.45	15.28	-5.43	14.21	15.29	-7.06
timebase.cc	13.24	14.44	-8.31	13.26	14.71	-9.86	13.37	14.58	-8.3	16.5	14.51	13.71	13.41	14.47	-7.33
ir.cc		59.49	53.89	10.39	83.8	80.16	4.54	106.06	127.22	-16.63	111.32	126.58	-12.06	109.25	129.06	-15.35
ir_base.cc	16.19	17.64	-8.22	21.22	19.41	9.33	19.48	21.36	-8.8	20.07	21.54	-6.82	19.6	21.63	-9.39
imr.cc		19.07	23.93	-20.31	23.66	27.56	-14.15	28.03	31.53	-11.1	29.63	32.09	-7.67	28.2	31.99	-11.85
mtdebug.cc	4.6	4.61	-0.22	4.65	5.03	-7.55	7.37	4.55	61.98	4.78	4.65	2.8	4.62	4.54	1.76

Sum		696.16	742.59	-6.25	829.94	862.54	-3.78	923.06	1023.99	-9.86	945.58	1039.36	-9.02	944.38	1023.43	-7.72



as you can see, there are some interesting files in the table (as a
regression I will mean slowdown by at least 15% as written on GCC
website):

Hand-written files:

typecode.cc: 3.4.0 compiles it more than 38% faster at -O1, but more than
             24 % slower at -O2, -O3 and -Os

static.cc: regression at -O3

valuetype_impl.cc: regression at -O1 and -O2

uni_base64.cc: regression at all levels, it's very short file and it seems
               3.4.0 is slower on startup
uni_touni.cc: the same example like uni_base64.cc


IDL compiler generated (machine generated) files:

ir.cc: like typecode.cc, faster at -O0 and -O1, but regression at -O2, -O3
       and -Os

imr.cc: regression at -O0 and also nearly at -O1

poa.cc: regeression at -O1


Also as you can see, every build was slower with GCC 3.4.0 in comparison
with GCC3.3.2.

I would also like to post bugreport to bugzilla, but I don't know how to
attach preprocessed file there. Is it possible to add them after clicking
on ``Commit'' button? Should I copy whole email table there, or is link to
gcc mailing list enough? (I'm afraid about table re-formating in html,
I don't have experience with it under Mozilla)

Thanks,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [UPDATED] GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Steven Bosscher]

On Tuesday 20 January 2004 10:21, Karel Gardas wrote:
> I would also like to post bugreport to bugzilla, but I don't know how to
> attach preprocessed file there. Is it possible to add them after clicking
> on ``Commit'' button? Should I copy whole email table there, or is link to
> gcc mailing list enough? (I'm afraid about table re-formating in html,
> I don't have experience with it under Mozilla)

You can add attachments after commiting the bug.  I suggest you add a
tarball of the preprocessed sources.

You don't have to put the whole table in the bug report.  In fact, please
don't :-)  A link to the message in the archives is enough.

Thanks,

Gr.
Steven

Re: [UPDATED] GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Karel Gardas]

On Tue, 20 Jan 2004, Steven Bosscher wrote:

> On Tuesday 20 January 2004 10:21, Karel Gardas wrote:
> > I would also like to post bugreport to bugzilla, but I don't know how to
> > attach preprocessed file there. Is it possible to add them after clicking
> > on ``Commit'' button? Should I copy whole email table there, or is link to
> > gcc mailing list enough? (I'm afraid about table re-formating in html,
> > I don't have experience with it under Mozilla)
>
> You can add attachments after commiting the bug.  I suggest you add a
> tarball of the preprocessed sources.

ACK.

> You don't have to put the whole table in the bug report.  In fact, please
> don't :-)  A link to the message in the archives is enough.

OK, I will do it, after testing tree-ssa for you. :-)

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [UPDATED] GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Giovanni Bajo]

Karel Gardas wrote:

> I would also like to post bugreport to bugzilla, but I don't know how
> to attach preprocessed file there. Is it possible to add them after
> clicking on ``Commit'' button?

Yes. Please, create a new bug report for *each* different regression. It's
easier for us to track and comment on them, since they're different bugs
anyway.

> Should I copy whole email table there, or is
> link to gcc mailing list enough? (I'm afraid about table re-formating in
html,
> I don't have experience with it under Mozilla)

For each bug, you can report the bugs that matter (and link to the mailing list
as a base reference for the discussion).

Thanks!
Giovanni Bajo

Re: [UPDATED] GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.

[Giovanni Bajo]

Giovanni Bajo wrote:

>> I would also like to post bugreport to bugzilla, but I don't know how
>> to attach preprocessed file there. Is it possible to add them after
>> clicking on ``Commit'' button?
>
> Yes. Please, create a new bug report for *each* different regression.
> It's easier for us to track and comment on them, since they're
> different bugs anyway.

Sorry for being unclear here: for *each* different regression, I meant just the
major ones, which you listed separately with a comment (8 testcases). You can
then open another "mother" bugreport with the whole tarball. We'll take care of
keeping the bug linked together.

Giovanni Bajo

Bugreports from MICO compile-time testing submited [was: Re: [UPDATED] GCC 3.4.0 20040114 + GCC 3.3.2 compile-time performance comparison on MICO project sources.]

[Karel Gardas]

On Tue, 20 Jan 2004, Giovanni Bajo wrote:

> Karel Gardas wrote:
>
> > I would also like to post bugreport to bugzilla, but I don't know how
> > to attach preprocessed file there. Is it possible to add them after
> > clicking on ``Commit'' button?
>
> Yes. Please, create a new bug report for *each* different regression. It's
> easier for us to track and comment on them, since they're different bugs
> anyway.

At the end I have just submited three general bugs: (13775, 13776, 13777).
If you need you can submit new one after the code analysis and if there
will be really different bugs. Also url to _all_ preprocessed sources are
provided in bugreports.

Cheers,

Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com