--- Comment #3 from vda dot linux at googlemail dot com 2010-02-04 14:33
---
I was bitten by this whet I was trying to get rid of
"warning: dereferencing type-punned pointer will break strict-aliasing rules"
on this fairly normal networking-related code:
if (cmsgptr-&
Summary: Suboptimal optimization: after x / 2 carry flag == x & 1
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #12 from vda dot linux at googlemail dot com 2009-06-21 16:48
---
Created an attachment (id=18041)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18041&action=view)
Comparison of generated code with 4.4.svn.20090528 on i86
--
http://gcc.gnu.org/b
--- Comment #11 from vda dot linux at googlemail dot com 2009-06-21 16:47
---
In 32-bit code, there are indeed a few cases of code growth.
Here is a full list (id_XXX are signed divides, ud_XXX are unsigned ones):
- 000f T id_x_4
+ 0012 T id_x_4
-
--- Comment #9 from vda dot linux at googlemail dot com 2009-06-21 16:12
---
Created an attachment (id=18040)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18040&action=view)
Comparison of generated code with 4.4.svn.20090528 on x86_64
--
http://gcc.gnu.org/b
--- Comment #8 from vda dot linux at googlemail dot com 2009-06-21 16:11
---
(In reply to comment #7)
> It seems to make sense to bump cost of idiv a bit, given the fact that there
> are register pressure implications.
>
> I would like to however understand what code
--- Comment #15 from vda dot linux at googlemail dot com 2008-08-20 15:07
---
(In reply to comment #13)
> Created an attachment (id=16113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16113&action=view) [edit]
> Updated doubleint-based patch. DOES NOT PASS TESTSU
--- Comment #14 from vda dot linux at googlemail dot com 2008-08-20 14:58
---
Created an attachment (id=16114)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16114&action=view)
Tree based patch. Passes bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
--- Comment #13 from vda dot linux at googlemail dot com 2008-08-20 14:57
---
Created an attachment (id=16113)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16113&action=view)
Updated doubleint-based patch. DOES NOT PASS TESTSUITE.
--
vda dot linux at googlemail
--- Comment #12 from vda dot linux at googlemail dot com 2008-08-18 13:02
---
Bootstrap with -O2 on current svn fails. Bootstrap with -Os works.
Bootstrap with -O2 on 4.3.1 works.
Instrumented patch emits C code which can be used to test for incorrect VRP
predictions.
I ran such
--- Comment #11 from vda dot linux at googlemail dot com 2008-08-11 12:46
---
Created an attachment (id=16050)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16050&action=view)
Updated patch. Uses double_int calculations instead of trees.
On Mon, 2008-08-04 at 14:2
--- Comment #10 from vda dot linux at googlemail dot com 2008-08-04 11:55
---
Created an attachment (id=16012)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16012&action=view)
Testcase to be added to testsuite
This program is artificially made to not compile if VRP f
--- Comment #9 from vda dot linux at googlemail dot com 2008-08-04 11:34
---
Created an attachment (id=16011)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16011&action=view)
The instrumented version of the patch
Set $VDA_DEBUG to the name of a file and gcc will appen
--- Comment #8 from vda dot linux at googlemail dot com 2008-08-04 11:28
---
Created an attachment (id=16010)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16010&action=view)
Example program which is compiled differently with this patch.
The difference is here:
--- Comment #7 from vda dot linux at googlemail dot com 2008-08-04 11:25
---
Created an attachment (id=16009)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16009&action=view)
Updated patch against current svn
This patch is bootstrapping successfully on current
--- Comment #9 from vda dot linux at googlemail dot com 2008-07-04 20:48
---
The above comment meant to say "4.3.1 have number of memory references down
from 115 _to 48_.
I also attached the best result so far - gcc-3.4.6 with -O3 genarates assembly
with smallest number of m
--- Comment #8 from vda dot linux at googlemail dot com 2008-07-04 20:38
---
Created an attachment (id=15856)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15856&action=view)
result of "gcc-3.4.6 -fomit-frame-pointer serpent.c -O3 -S"
--
http://gcc
--- Comment #7 from vda dot linux at googlemail dot com 2008-07-04 20:33
---
4.3.1 have number of memory references down from 115 (4.2.1 had that) but still
can't regain the result of 3.4.3 (21 memory reference). Here is how I checked
this:
# i486-linux-uclibc-gcc -v
...
gcc ve
--- Comment #1 from vda dot linux at googlemail dot com 2008-05-20 19:48
---
Simplified case:
#pragma weak __pthread_initialize
extern void *memcpy(void *dest, const void *src, int n);
extern typeof(memcpy) memcpy asm("__GI_memcpy");
void f(void) {}
--
http://g
1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC tar
--- Comment #7 from vda dot linux at googlemail dot com 2007-08-31 11:30
---
This is unfortunate, it skews busybox's "make bloatcheck" results.
In general, I suppose if generated asm sequences are different -> one of them
is "better" (for some definition o
--- Comment #5 from vda dot linux at googlemail dot com 2007-08-28 14:49
---
Created an attachment (id=14125)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14125&action=view)
An example of code compiled differently by 4.2.1
It still exists in 4.2.1
testcase-421 c
--- Comment #3 from vda dot linux at googlemail dot com 2007-08-21 12:26
---
Created an attachment (id=14088)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14088&action=view)
assembler output generated by 4.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
--- Comment #2 from vda dot linux at googlemail dot com 2007-08-21 12:26
---
Created an attachment (id=14087)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14087&action=view)
assembler output generated by 4.1.1
Sorry, don't have native gcc 4.1.1 at this machine, b
--- Comment #1 from vda dot linux at googlemail dot com 2007-08-21 12:23
---
Created an attachment (id=14086)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14086&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
--- Comment #5 from vda dot linux at googlemail dot com 2007-07-25 15:22
---
Forgot to mention:
* generator tests signed and unsigned divisions and modulus, both const / x and
x / const, and also tests u = a / b; v = a % b; construct.
* you need to filter gen_test output to weed out
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-25 15:17
---
Created an attachment (id=13975)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13975&action=view)
Test program generator
Test program was generated using gen_test.c
--
http://gcc.gnu.org/b
--- Comment #3 from vda dot linux at googlemail dot com 2007-07-25 15:09
---
Created an attachment (id=13974)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13974&action=view)
Auto-generated test program with 15000 constant divs/mods
Test program, bzipped.
Build with
gcc
--- Comment #2 from vda dot linux at googlemail dot com 2007-07-25 15:05
---
Created an attachment (id=13973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13973&action=view)
Fix: adjust div cost for -Os on i386
Patch was tested with 4.2.1, I guess it will apply t
--- Comment #7 from vda dot linux at googlemail dot com 2007-07-23 20:50
---
I want to apologise. Apparently this behavior (16-byte stack alignment) can be
turned off with an option => I can still have just word-aligned stack. As long
as that still works, I am a more-or-less ha
--- Comment #16 from vda dot linux at googlemail dot com 2007-07-23 00:48
---
You have it reversed here:
"8. Stack alignment is already implemented in Gcc and existing code relies on
it."
No, stack alignment is _not_ in current de-facto i386 Linux ABI and there are
tons o
--- Comment #6 from vda dot linux at googlemail dot com 2007-07-23 00:15
---
Oh *shit*. I see. Why, oh why you didn't go for aligning stack in fuctions
which decided they need to use instructions which require alignment? And ONLY
that functions? Why everyone needs to pay this ta
--- Comment #27 from vda dot linux at googlemail dot com 2007-07-23 00:06
---
May I point that alternative solution (to align stack _in the function which
needs it_) doesn't crash if called by code generated by old or new gcc, and
also gives smaller, faster and less stack cons
--- Comment #15 from vda dot linux at googlemail dot com 2007-07-23 00:03
---
Disadvantages of enforcing 16-bytes stack alignment, continued:
* Code to align the stack is generated when we call a function, even when this
function isn't going to use SSE. Which is ~90% of all func
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-22 21:32
---
I am confused...
How does reserving 12 bytes on stack can help to prevent a segfault?
I can imagine how aligning the stack can help, but here gcc 4.2.1 does
something diffrent.
Maybe just throw an URL to more
--- Comment #2 from vda dot linux at googlemail dot com 2007-07-22 10:16
---
Well, gcc 3.4.3 disagrees with you:
# gcc -Os -fomit-frame-pointer -S t.c
# cat t.s
.file "t.c"
.text
.globl t
.type t, @function
t:
callf
testl
--- Comment #5 from vda dot linux at googlemail dot com 2007-07-22 00:10
---
Basically, the reason for the regression is that 4.2.1 doesn't figure out how
to use i386 registers efficiently. 3.4.3 was able to do it. Difference in
assembly:
# grep 'mov.*(' serpent-343-
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-22 00:02
---
With t.c being a timing program from comment #3 and serpent.c from attachment,
I build testing program for 3.4.3, 3.4.6 and 4.2.1, -Os and -O3, like this:
ver=NNN
gcc -Os -o serpent-${ver}-Os serpent.c t.c
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-21 23:41
---
Tested gcc 4.2.1, generates identical code:
00aa T find_pair
00aa T find_pairB
00aa T find_pairC
00aa T find_pair
00aa T find_pairB
00aa T find_pairC
Also did a diff of .s files
--- Comment #1 from vda dot linux at googlemail dot com 2007-07-21 23:36
---
With 4.2.1 gcc regressed a bit:
gcc -Os -fomit-frame-pointer -S u.c
.file "u.c"
.text
.globl f
.type f, @function
f:
subl$12, %esp
cmpl$1
Summary: Unnecessary %esp inc/decrements in trivial code
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #3 from vda dot linux at googlemail dot com 2007-03-23 12:00
---
You are right, in current svn it is fixed.
BTW I think I see a bug created by this change: with -Os x86_86 ABI will be
violated - arrays larger than 16 bytes will still be aligned only to 4 bytes
because if&#
--- Comment #1 from vda dot linux at googlemail dot com 2007-03-22 20:07
---
Patch is available here:
http://busybox.net/~vda/mbigdata_align.diff
I cannot attach patch to this bugzilla entry because I get this:
"Internal Error
GCC Bugzilla has suffered an internal error. P
mponent: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
--- Comment #5 from vda dot linux at googlemail dot com 2007-01-28 17:40
---
http://david.tribble.com/text/cdiffs.htm#C99-string-const
"In C, string literals have type char[n], but are not modifiable (i.e.,
attempting to modify the contents of a string literal is undefined beh
--- Comment #3 from vda dot linux at googlemail dot com 2007-01-28 17:25
---
Sorry! Bug in the testcase, should be "char *p".
I remember that string literals are special - they decay to "const char *" OR
to "char*" depending on context. In this context, i
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
y: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bug
--- Comment #3 from vda dot linux at googlemail dot com 2006-11-27 23:03
---
Super! Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30004
have a patch there...
--
Summary: overzealous alignment of structure - 32 bytes (not
bits!)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assig
jmp g
*/
--
Summary: suboptimal code generation
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda
--- Comment #2 from vda dot linux at googlemail dot com 2006-11-22 22:58
---
Created an attachment (id=12670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12670&action=view)
Complete testcase with .c, .o and .s files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #1 from vda dot linux at googlemail dot com 2006-11-22 22:57
---
Created an attachment (id=12669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12669&action=view)
Visual comparison of assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
-pc-linux-gnu
Thread model: posix
gcc version 4.1.1
--
Summary: Generated code changes after unrelated edits in source.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimizat
--- Comment #6 from vda dot linux at googlemail dot com 2006-08-11 14:17
---
Created an attachment (id=12067)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12067&action=view)
New version of the patch. 4.1.1 bootstraps with it.
--
vda dot linux at googlemail dot com
--- Comment #3 from vda dot linux at googlemail dot com 2006-08-07 11:26
---
Differences in *.vrp (-fdump-tree-vrp output) and assembly generated
with stock 4.1.1 and with patched one out of test program test_vrp.c
--- test_vrp.c.t36-411org.vrp 2006-08-06 22:40:04.0 +0200
--- Comment #2 from vda dot linux at googlemail dot com 2006-08-07 11:14
---
Created an attachment (id=12036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12036&action=view)
Test program which demonstrates how VRP generates simpler code
--
http://gcc.gnu.org/b
--- Comment #1 from vda dot linux at googlemail dot com 2006-08-07 11:13
---
Created an attachment (id=12035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12035&action=view)
The patch relative to 4.1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
RMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet:
--- Comment #14 from vda dot linux at googlemail dot com 2006-08-04 18:14
---
>But since these sort of transformations are of
>a very mathematical nature, I trust the author of the
>suggested changes has proven the algorithms?
I did not write a paper about it, but I think I
--- Comment #12 from vda dot linux at googlemail dot com 2006-08-03 17:06
---
Created an attachment (id=12005)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12005&action=view)
Alternative algorithm v. 3
Formatting fixes mostly
--
vda dot linux at googlemail dot com
--- Comment #10 from vda dot linux at googlemail dot com 2006-08-02 19:05
---
Created an attachment (id=12000)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12000&action=view)
Alternative algorithm v. 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
--- Comment #9 from vda dot linux at googlemail dot com 2006-08-02 19:05
---
Thanks for the link to .pdf! Who's Tege? And his email address is ...?
Ok. This new version of the patch is working for signed divisions too, and is
giving the results which are always same or better
--- Comment #7 from vda dot linux at googlemail dot com 2006-07-30 13:43
---
Created an attachment (id=11973)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11973&action=view)
Random tester
Randomly chooses a/b and compares "gcc patch code" results with code whi
--- Comment #6 from vda dot linux at googlemail dot com 2006-07-30 13:38
---
Patched versus stock gcc-4.1.1 on this code
unsigned v;
void f9188_mul365384439_shift27(unsigned A) { v = A/(unsigned)1577682821; }
is:
# diff -u suboptimal-411-O2.s suboptimal-411-O2-fixed.s
--- suboptimal
--- Comment #5 from vda dot linux at googlemail dot com 2006-07-30 13:37
---
Created an attachment (id=11972)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11972&action=view)
Test program
Compile with -O2 -S to see the assembly.
Compile with -Os and run to check the corr
--- Comment #4 from vda dot linux at googlemail dot com 2006-07-30 13:35
---
Created an attachment (id=11971)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11971&action=view)
Use alternative algorithm if it gives better results
New algorithm lives in separate f
--- Comment #3 from vda dot linux at googlemail dot com 2006-07-25 17:18
---
With this test program:
#include
#include
typedef unsigned u32;
struct serpent_ctx { u32 expkey[132]; };
void serpent_encrypt(void *ctx, u32 *dst, const u32 *src);
u32 v[4],u[4];
struct serpent_ctx ctx;
int
--- Comment #1 from vda dot linux at googlemail dot com 2006-07-25 14:45
---
Created an attachment (id=11934)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11934&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481
gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC h
--- Comment #3 from vda dot linux at googlemail dot com 2006-07-19 16:24
---
I instrumented choose_multiplier(). When called like this:
choose_multiplier(d=1577682821,n=32,precision=32),
it returns *post_shift_ptr=31,multiplier=5846151023
whereas optimal one is *post_shift_ptr=27
--- Comment #2 from vda dot linux at googlemail dot com 2006-07-18 12:06
---
Pseudo-code to help in reading above code:
void fastdiv_params(unsigned B, unsigned max_A)
{
L = (max_unsigned_long_long/max_unsigned - 1) * B;
L = largest_pow2_smaller_or_eq_to(L
--- Comment #1 from vda dot linux at googlemail dot com 2006-07-18 08:40
---
I didn't look too close at choose_multiplier(), yet.
If anybody will work upon it in order to make it better,
this is the routine which prints values 'K' and 'bits'
so that
(A*K)
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
--- Comment #11 from vda dot linux at googlemail dot com 2006-07-17 10:32
---
Andrew, I must be extremely dumb today. I looked in the source and for the life
of me, I can't see where that optimization is done. I even generated a
2.6.1->2.6.1 diff where it was added and still d
--- Comment #4 from vda dot linux at googlemail dot com 2006-07-17 09:09
---
Wow, this looks nice, good job! Thanks!
--
vda dot linux at googlemail dot com changed:
What|Removed |Added
cc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28405
--- Comment #10 from vda dot linux at googlemail dot com 2006-07-16 18:54
---
gcc-4.1.1 differs only by insterting one more useless insn:
movl$-858993459, %eax
mull8(%esp)
movl%edx, %eax
+ xorl%edx, %edx
shrl$3, %eax
--- Comment #9 from vda dot linux at googlemail dot com 2006-07-16 18:47
---
The test program below shows that in this case doing division with div insn
takes more instructions than with mul+shift.
Also mul+shift path has absolutely useless "movl %edx, %eax" insn, shaving
--- Comment #7 from vda dot linux at googlemail dot com 2006-07-16 16:22
---
Oh my.
It looks that use of -Os played a joke on me. gcc 3.4.3 -Os uses a division
instruction, even though it results in slower and _also bigger_ code.
Maybe it makes sense to enable this optimization for
--- Comment #3 from vda dot linux at googlemail dot com 2006-07-16 15:46
---
Created an attachment (id=11900)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11900&action=view)
find_fast_div_random.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
--- Comment #2 from vda dot linux at googlemail dot com 2006-07-16 15:46
---
Created an attachment (id=11899)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11899&action=view)
fast_div_bench.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
--- Comment #1 from vda dot linux at googlemail dot com 2006-07-16 15:45
---
Created an attachment (id=11898)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11898&action=view)
find_fast_div.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
de
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
85 matches
Mail list logo
