--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-20 07:57 ---
FX wrote:
> > http://gcc.gnu.org/onlinedocs/gfortran/Implicitly-convert-LOGICAL-and...
> I think this is only true for assignments, ie you can assign a logical
> value to an integer lhs and the other way around. The
--- Comment #43 from stevenb dot gcc at gmail dot com 2007-12-20 06:15
---
Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions
I did not mean more bitmaps but more elements per bitmap, obviously.
I know the effect of the patch, or I wouldn't have written it ;
--- Comment #4 from tbm at cyrius dot com 2007-12-20 05:07 ---
I marked it as a 4.3 regression because I believe 4.2 was able to compile
the code. If you think it applies to 4.2, maybe it would be a good idea
to apply the patch there as well.
BTW, it might be a good idea to check in th
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52
---
Created an attachment (id=14799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799&action=view)
memory details for an unpatched mainline
Here is the same information without Steven's two patches for mai
--- Comment #9 from spop at gcc dot gnu dot org 2007-12-20 03:46 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from spop at gcc dot gnu dot org 2007-12-20 03:42 ---
Subject: Bug 34413
Author: spop
Date: Thu Dec 20 03:42:17 2007
New Revision: 131097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131097
Log:
2007-12-19 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-opt
--- Comment #41 from zadeck at naturalbridge dot com 2007-12-20 03:06
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
> --- Comment #40 from lucier at math dot purdue dot edu 2007-12-20 02:29
> ---
> Created an attachment
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-20 02:33
---
I think it should continue to be rejected. We don't need to encourage mushy
typing in fortran code. I vote fix the documentation if needed. The user
should do:
if (i /= 0) print *, "whatever you think you ne
--- Comment #40 from lucier at math dot purdue dot edu 2007-12-20 02:29
---
Created an attachment (id=14798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14798&action=view)
detailed memory usage report
I rebuilt mainline with --enable-gather-detailed-mem-stats and this is the
ou
--- Comment #7 from hailijuan at gmail dot com 2007-12-20 02:21 ---
fixed in revision 131059
--
hailijuan at gmail dot com changed:
What|Removed |Added
Status
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-12-20 02:08 ---
This was introduced by the change to rs6000_legitimate_offset_address_p which
was done by:
PR target/18506
* config/rs6000/altivec.md (vec_init): New.
(vec_set): New.
(vec_extract): Ne
--- Comment #42 from zadeck at naturalbridge dot com 2007-12-20 01:56
---
Subject: Re: [4.3 regression] bad interaction between
DF and SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #41 from steven at gcc dot gnu dot org 2007-12-19 23:57
> ---
> Patches
--- Comment #3 from danglin at gcc dot gnu dot org 2007-12-20 01:42 ---
Fixed by change.
What are the reasons this was marked as a 4.3 regression? I'm interested
when the regression occurred since the backend has never forced function
labels to memory in this code.
A simpler testcase
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-20 01:21 ---
Confirmed.
> I think these were caused by:
> http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00728.html
Actually it is obvious it was caused by that patch based on the backtrace.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 01:20 ---
I get these failures too on powerpc-linux-gnu.
I think these were caused by:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00728.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from danglin at gcc dot gnu dot org 2007-12-20 01:18 ---
Subject: Bug 34525
Author: danglin
Date: Thu Dec 20 01:17:57 2007
New Revision: 131096
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131096
Log:
PR target/34525
* pa.c (legitimize_pic_addres
gnu/gcc-4.3/gcc/libstdc++-v3/libsupc++
/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/include/backward
/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/util
/home/dave/gnu/gcc-4.3/objdir/./gcc/include
/home/dave/gnu/gcc-4.3/objdir/./gcc/include-fixed
/home/dave/opt/gnu/include
/usr/include
End of sea
--- Comment #7 from dsanderson at panasas dot com 2007-12-20 00:17 ---
Note that my originally stated workaround -- to compile with -maix64 -- doesn't
really work beyond helping the compile to succeed. Using -maix64 gives you a
64-bit executable (e.g. with 64-bit pointers and a 64-bit o
On Linux/ia64, I saw
FAIL: gcc.dg/struct/wo_prof_global_var.c execution test
FAIL: gcc.dg/struct/wo_prof_local_var.c execution test
FAIL: gcc.dg/struct/wo_prof_mult_field_peeling.c execution test
FAIL: gcc.dg/struct/wo_prof_two_strs.c execution test
They are run-time failures.
--
Su
--- Comment #5 from hjl at lucon dot org 2007-12-20 00:15 ---
(In reply to comment #4)
> Thank you for debugging! Now I see approximately where it fails. Although I am
> not sure that the following patch solves the issue, please try it, and let me
> know whether it helps.
>
> Thank you
--- Comment #6 from tcoleman at autowares dot com 2007-12-20 00:06 ---
The test program will compile if you comment out the #undefs in cstdio.
//#undef fgetpos
//#undef fopen
//#undef freopen
//#undef fsetpos
I've wrestled with this problem with G++ on AIX for years. In desparation I
--- Comment #39 from steven at gcc dot gnu dot org 2007-12-20 00:02 ---
We badly need a way to track memory in DF. Because DF uses alloc_pools for
almost all its data structures, the memory statistics are only recorded if you
configure with --gather-detailed-mem-stats. I think it would
--- Comment #41 from steven at gcc dot gnu dot org 2007-12-19 23:57 ---
Patches attached to this bug report address more general issues, namely:
1. The LIVE problem allocates too many bitmaps (xf. df_hack2.diff)
2. Large and very connected CFGs are a time problem
Bug 26854 is another e
refix=/pkgs/gcc-mainline
--enable-languages=c --enable-checking=release --with-gmp=/pkgs/
gmp-4.2.2 --with-mpfr=/pkgs/gmp-4.2.2
Thread model: posix
gcc version 4.3.0 20071219 (experimental) [trunk revision 131091] (GCC)
euler-33% /pkgs/gcc-mainline/bin/gcc -O1 -fno-math-errno -fschedule-
in
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-19 23:01 ---
I should note this is a reduced testcase from a much bigger testcase and that I
could not provide that non reduced testcase as it is part of some PS3 video
game.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34
--- Comment #40 from steven at gcc dot gnu dot org 2007-12-19 22:49 ---
The issue with tree PRE is probably the quadratic behavior of insert(). Easily
tested by lowering the maximum number of basic blocks from 4000 to 2000 (even
though that's obviously not an actual fix for this problem
Found by Dominique.
For the first call, DTIME and ETIME (should) behave identical: The elapsed time
since invocation should be returned. (This works.)
ETIME does this also for the following calls, but DTIME shall do the following:
"Subsequent invocations of DTIME return values accumulated since
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-19 22:33 ---
Patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00245.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
--- Comment #37 from steven at gcc dot gnu dot org 2007-12-19 22:13 ---
Brad,
I am looking at your dump and your backtraces (many many thanks!!!) and I think
I have an idea how to improve the situation a bit here:
> Program received signal SIGINT, Interrupt.
> 0x004687c9 in bit
--- Comment #27 from ubizjak at gmail dot com 2007-12-19 22:02 ---
(In reply to comment #26)
> Bring back on the radar for the release manager.
> New timings would be much appreciated. Anyone?
Attached preprocessed source doesn't compile out-of-the-box with gcc-4.3.
--
http://gcc.
--- Comment #36 from lucier at math dot purdue dot edu 2007-12-19 21:48
---
I changed the "reported against" field to 4.3.0 (see my previous comments).
--
lucier at math dot purdue dot edu changed:
What|Removed |Added
-
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-19 20:55 ---
This will probably never be fixed in a generic way. Systems which require this
(legit) behaviour will have non-backward-jumping clocks anyway.
Letting open, but changing priority.
--
sam at gcc dot gnu dot org chang
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-19 20:52 ---
Compiles fine on trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|
ate patch, keeping just tree-ssa-dse.c (dse_optimize_stmt) hunk
together with the new 20071219-1.c test as the fix for this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34459
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-19 20:49 ---
Already fixed in trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-19 20:48 ---
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/30039cbb71280a3b/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34532
http://gcc.gnu.org/onlinedocs/gfortran/Implicitly-convert-LOGICAL-and-INTEGER-values.html
INTEGER :: i = 1
IF (i) PRINT *, 'True'
The program is rejected here with gfortran 4.1, 4.2 and 4.3 using -std=legacy.
--
Summary: Doc error or rej.valid vendor extensio
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34149
--- Comment #9 from sam at gcc dot gnu dot org 2007-12-19 20:38 ---
Fixed by Arnaud's commit.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from sam at gcc dot gnu dot org 2007-12-19 20:37 ---
Fixed by Arnaud's commit.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #1 from dominiq at lps dot ens dot fr 2007-12-19 19:19 ---
The bug is present in gcc version 4.3.0 20071125 (experimental) (GCC).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
--- Comment #4 from olga at gcc dot gnu dot org 2007-12-19 18:57 ---
Thank you for debugging! Now I see approximately where it fails. Although I am
not sure that the following patch solves the issue, please try it, and let me
know whether it helps.
Thank you a lot,
Olga
Index: ipa-str
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #3 from rbuergel at web dot de 2007-12-19 18:50 ---
If the error is correct, then at least the error message is confusing.
It complains that Y::X redeclares ::X, although the real cause of the error is,
that it may not be clear to that compiler what X refers to
--
http:
--- Comment #1 from janis at gcc dot gnu dot org 2007-12-19 18:50 ---
I'd like to see -mabi=altivec be the default for -m32, with -mabi=no-altivec
available for the rare cases when it's needed. Would changing the default
cause any problems?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-19 17:40 ---
Actually the error message is correct. Use ::X instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34531
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
|
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-19 17:03 ---
Created an attachment (id=14797)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14797&action=view)
gcc43-pr34459.patch
Untested patch. The gimplify.c part is there just as an optimization, isn't
strictly necessa
--- Comment #1 from rbuergel at web dot de 2007-12-19 16:55 ---
It fails only on 4.3.0:
gcc version 4.3.0 20071214 (experimental) (GCC)
--
rbuergel at web dot de changed:
What|Removed |Added
---
--- Comment #8 from charlet at adacore dot com 2007-12-19 16:50 ---
Subject: Re: Illegal program not detected, RM 8.3(19)
> for traceability purpose, I would appreciate to be credited in the ChangeLog
> as
> well for this change as I am the one who submitted the patch for sem_ch3.adb
>
--- Comment #7 from sam at gcc dot gnu dot org 2007-12-19 16:46 ---
Arnaud,
for traceability purpose, I would appreciate to be credited in the ChangeLog as
well for this change as I am the one who submitted the patch for sem_ch3.adb
(Check_For_Premature_Usage procedure and Access_Subpro
template class X {};
class Y {
typedef X X;
};
produces the following error:
redef.cpp:4: error: declaration of 'typedef class X Y::X'
redef.cpp:1: error: changes meaning of 'X' from 'class X'
I don't think, that the error is correct, because as the typedef is inside a
class-definition
--- Comment #5 from charlet at gcc dot gnu dot org 2007-12-19 16:26 ---
Subject: Bug 33688
Author: charlet
Date: Wed Dec 19 16:25:58 2007
New Revision: 131084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131084
Log:
2007-12-19 Thomas Quinot <[EMAIL PROTECTED]>
Part
--- Comment #3 from charlet at gcc dot gnu dot org 2007-12-19 16:25 ---
Subject: Bug 34149
Author: charlet
Date: Wed Dec 19 16:25:18 2007
New Revision: 131082
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131082
Log:
2007-12-19 Gary Dismukes <[EMAIL PROTECTED]>
PR ad
--- Comment #6 from charlet at gcc dot gnu dot org 2007-12-19 16:24 ---
Subject: Bug 15803
Author: charlet
Date: Wed Dec 19 16:24:34 2007
New Revision: 131079
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131079
Log:
2007-12-19 Ed Schonberg <[EMAIL PROTECTED]>
Gar
dear all,
i am turning to the email since it would be almost impossible to make a
regular bug report.
we are building a large c++ software for the international pierre auger
collaboration which has build the world's largest cosmic ray detector.
more than a year ago we have come across a bug (on
--- Comment #5 from haubi at gentoo dot org 2007-12-19 15:57 ---
Created an attachment (id=14796)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14796&action=view)
the effect fixincludes could have on aix5.2/aix5.3
When applying this patch to (already fixed) stdio.h on aix5.2/aix5.
--- Comment #4 from jakub at gcc dot gnu dot org 2007-12-19 15:31 ---
extern void abort (void);
extern void *memset (void *s, int c, __SIZE_TYPE__ n);
struct S
{
char s[25];
};
struct S *p;
void __attribute__((noinline))
foo (struct S *x, int set)
{
int i;
for (i = 0; i < sizeof
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-12-19 15:01 ---
Subject: Bug 34355
Author: rakdver
Date: Wed Dec 19 15:01:19 2007
New Revision: 131063
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131063
Log:
PR tree-optimization/34355
* tree-parloops.c
--- Comment #23 from jakub at gcc dot gnu dot org 2007-12-19 14:48 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #22 from bonzini at gnu dot org 2007-12-19 14:28 ---
Subject: Bug 30572
Author: bonzini
Date: Wed Dec 19 14:28:32 2007
New Revision: 131062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131062
Log:
2007-12-19 Etsushi Kato <[EMAIL PROTECTED]>
Paolo Bonz
--- Comment #18 from rask at gcc dot gnu dot org 2007-12-19 14:15 ---
Created an attachment (id=14795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14795&action=view)
(u)mulsidi3 patch
This patch (in testing) improves the register allocation, removing the last
redundant movl inst
Hi,
namelist read was broken between
GNU Fortran (GCC) 4.3.0 20071216 (experimental) [trunk revision 130986]
(works)
GNU Fortran (GCC) 4.3.0 20071217 (experimental) [trunk revision 131004]
(fails).
This is likely due to the patch for PR34427.
Example: the code below now gives
At line 17 of fi
--- Comment #39 from bonzini at gnu dot org 2007-12-19 13:57 ---
Yes, we need a no-checking comparison. And this might be a PR of its own, for
example:
tree PRE : 7.94 (15%) usr 0.10 (32%) sys 8.04 (15%) wall
1687 kB ( 2%) ggc
--
http://gcc.gnu.org/bugzilla/
--- Comment #26 from bonzini at gnu dot org 2007-12-19 13:53 ---
I'm starting a SPEC run on the overall patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #25 from bonzini at gnu dot org 2007-12-19 13:50 ---
Note that "fwprop" is not an exact term, because there *is* a memory load in
each multiplication, and propagating a second memory operand will create an
invalid insn. You may try to add a split from reg=op(mem1, mem2) to
r
--- Comment #24 from steven at gcc dot gnu dot org 2007-12-19 13:48 ---
The patch in comment #23 might even be suitable for GCC 4.3 ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #23 from bonzini at gnu dot org 2007-12-19 13:36 ---
Created an attachment (id=14794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14794&action=view)
teach combine that reg = op(reg, mem) is better
Since combine operates on the whole pattern, it can be taught the tric
--- Comment #22 from ubizjak at gmail dot com 2007-12-19 13:11 ---
(In reply to comment #21)
> Indeed, if I only use the regclass.c and local-alloc.c hunks, I get only one
> spill!
>
> pushl %ebx
> movl8(%esp), %edx
> movl16(%esp), %eax
> movl
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-19 13:01 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Assi
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-19 12:58 ---
Subject: Bug 34513
Author: jakub
Date: Wed Dec 19 12:58:32 2007
New Revision: 131059
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131059
Log:
PR c++/34513
* parser.c (cp_parser_omp_parallel):
--- Comment #21 from bonzini at gnu dot org 2007-12-19 12:43 ---
Created an attachment (id=14793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14793&action=view)
two hunks only from the previous patch
Indeed, if I only use the regclass.c and local-alloc.c hunks, I get only one
sp
--- Comment #20 from bonzini at gnu dot org 2007-12-19 12:32 ---
There is a big catch-22. When GCC ties one of regs 64/66 with reg 61, it
enlarges reg 61's live range to cover the live range of the tied range. When
it does this, it basically locks up %edx for the whole live range of re
--- Comment #19 from bonzini at gnu dot org 2007-12-19 12:13 ---
Created an attachment (id=14792)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14792&action=view)
patch to almost fix the bug
With this patch:
1) local-alloc first tries to allocate registers that go into small class
--- Comment #18 from ubizjak at gmail dot com 2007-12-19 12:11 ---
Another baby step can be performed by:
Index: optabs.c
===
--- optabs.c(revision 131053)
+++ optabs.c(working copy)
@@ -1245,7 +1245,7 @@ expand_dou
--- Comment #10 from rsandifo at gcc dot gnu dot org 2007-12-19 10:08
---
Thanks for the patch. Now applied to 4.1 and 4.2.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from rsandifo at gcc dot gnu dot org 2007-12-19 10:06
---
Subject: Bug 34456
Author: rsandifo
Date: Wed Dec 19 10:05:47 2007
New Revision: 131058
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131058
Log:
gcc/
200x-xx-xx Kaz Kylheku <[EMAIL PROTECTED]>
--- Comment #7 from hainque at adacore dot com 2007-12-19 10:06 ---
Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto
away and I cannot debug
Olivier Hainque wrote:
> We can definitely resubmit the current version we have (I copied the
> author). Thanks aga
--- Comment #8 from rsandifo at gcc dot gnu dot org 2007-12-19 10:04
---
Subject: Bug 34456
Author: rsandifo
Date: Wed Dec 19 10:04:28 2007
New Revision: 131057
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131057
Log:
gcc/
200x-xx-xx Kaz Kylheku <[EMAIL PROTECTED]>
--- Comment #17 from bonzini at gnu dot org 2007-12-19 09:49 ---
With this patch, GCC gets the preferences right, but it does not affect code
generation.
Index: regclass.c
===
--- regclass.c (revision 130928)
+++ regclass.
--- Comment #4 from jakub at gcc dot gnu dot org 2007-12-19 09:46 ---
We could even TODO_rebuild_alias only if vectorizer changed anything...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
--- Comment #3 from dorit at gcc dot gnu dot org 2007-12-19 09:38 ---
> This is a vectorizer vs not being able to run may_alias after it
can you please remind me why we can't run may_alias after the vectorizer? (and
what do you think can be done about it?)
--
http://gcc.gnu.org/bug
--- Comment #3 from bonzini at gnu dot org 2007-12-19 09:37 ---
Makes a lot of sense. I made the patch only to test that it would not crash,
or something like that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34522
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-19 09:08 ---
Shouldn't tmode be only used if GET_MODE_CLASS (tmode) == MODE_INT
&& GET_MODE_CLASS (mode) == MODE_INT && GET_MODE_BITSIZE (tmode) <
GET_MODE_BITSIZE (mode), to make sure we optimize only narrow, never widen, and
that
--- Comment #6 from hainque at adacore dot com 2007-12-19 08:30 ---
Subject: Re: [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto
away and I cannot debug
Hi Steven,
steven at gcc dot gnu dot org wrote:
> xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html
>
> I
85 matches
Mail list logo
