--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 02:44
---
Marked as P5; this will never be release critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #44 from mmitchel at gcc dot gnu dot org 2005-10-31 02:44
---
Leaving as P2; we should at least look hard at all of this again for 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 02:46
---
Downgraded to P2; it would be good to fix this, but it's not valid code, so
it's not a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 02:46
---
Leaving as P2; I've been tinkering with a possible patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 02:47
---
Marked as P5; this will never be release critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 02:49
---
Leaving as P2; we should try to fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20293
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 02:51
---
Dan, is there any chance of fixing this for 4.1?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-31 02:55
---
Given the kind of solutions we're looking at, I can't imagine this being fixed
for 4.0, and probably not even for 4.1, so I've set this to P4.
However, it seems sad to me that we can't find some efficient way to
--- Comment #17 from mmitchel at gcc dot gnu dot org 2005-10-31 03:06
---
This prevents compiling a reasonably popular program; it's a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:08
---
On the one hand, varargs functions generally aren't used where performance
really matters. On the other, this seems like something that shouldn't be too
hard to fix -- and there's a code-size regression here too.
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 03:09
---
Leaving as P2; this should be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21228
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 03:11
---
I had another round of thoughts about this bug. It's clear that we need better
data structures to get this right. It's not clear that I know what they should
be.
In any case, yes, we should try to ameliorate t
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 03:13
---
Yes, we should fix this -- but it's never going to be release critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 03:14
---
Downgraded to P5; this will never be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 03:15
---
Leaving as P2; we really ought to fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21391
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-10-31 03:21
---
We need more analysis on these kinds of issues.
So, we're doing a worse job on register allocation. Is that because the
register allocator got worse, or because we're giving it a harder problem to
solve? If the
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-10-31 03:27
---
Like Diego, I'd like to understand this PR better. Not with a guess, but with
a concrete explanation. If there's an overlapping live range, what range is
it? In order to understand these kinds of optimization P
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 03:31
---
This will never be release critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-10-31 03:35
---
It sounds like we should (a) forbid __attribute__((regparm(3)) with -fPIC, and
(b) not automatically generate that value, as per the patch in Comment #9. It
doesn't seem useful to have an option that we think is
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 03:36
---
Leaving this as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:37
---
We should definitely fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21627
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-10-31 03:37
---
(In reply to comment #11)
> So, we're doing a worse job on register allocation. Is that because the
> register allocator got worse, or because we're giving it a harder problem to
> solve? If the latter, what's re
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 03:38
---
This will never be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 03:40
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21715
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:43
---
Downgraded to P2. Important, but not a showstopper. We really should have
some kind of throttle, even if it's a bit simplistic.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-10-31 03:43 ---
Realistically?
No.
I'm about to start solving it on the improved-aliasing branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 03:45
---
Leaving at P2, only because Cygwin is not a primary platform. (Otherwise, I'd
make this P1.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 03:46
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22042
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 03:49
---
Regardless of *where* getcontext() should be recognized, it's clear that the
compiler should be aware that it has special behavior.
This is a wrong-code regression on a primary platform with no non-default
opti
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 03:50
---
Leaving as P2; we should fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 03:54
---
Leaving as P2.
Do we know what's different? The structure type is byte-aligned. How did 2.95
justify using a 4-byte store?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 03:55
---
Gaby, please apply the simple OBJ_TYPE_REF patch so that we can remove the
regression markers from this PR.
(I agree that a complete solution is difficult; my opinion continues to be that
we should use carets, rat
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:57
---
This is a showstopper; we need to at least understand why this changed and
whether or not we should change it back.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-31 03:59 ---
(In reply to comment #2)
> Leaving as P2.
> Do we know what's different?
Yes in 4.0 and above there is no CONSTRUCTOR so we don't see the full
CONSTRUCTOR in expand so it could expand to just one integer store.
>The
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 04:02
---
The patch in Comment #1 has been applied.
Andrew, what is your point about the C++ front-end? What is it you think is
wrong?
In any case, this will never be release critical.
--
mmitchel at gcc dot gnu dot o
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-10-31 04:03
---
This is a showstopper; wrong code on a primary platform using plausible inputs.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:04
---
This is a showstopper; wrong code on a primary platform.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 04:05
---
I'm not sure what's ging on here, but I know we should fix it... Leaving as
P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22434
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 04:07
---
This will never be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:07
---
This will prevent compiling real programs with -g; it's a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-31 04:08
---
I've set this to P5. If it's not Fortran-specific, Cc: me -- after attaching
the C/C++ test-case. Or, just fix the bug. :-)
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-10-31 04:10
---
Downgraded to P5. If this is not Ada-specific, please attach a C/C++ test
case.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:12
---
Leaving as P2.
I've seen reports of similar bitfield problems on a variety of problems. This
kind of code doesn't show up much in scientific computing, but it does show up
in network applications, operating-syste
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-31 04:13 ---
(In reply to comment #3)
> Andrew, what is your point about the C++ front-end? What is it you think is
> wrong?
There is no mention of the C++ front-end here at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-31
04:15 ---
More data, the Linux kernel compiled for i686:
size -f *
textdata bss dec hex filename
2625471 534012 611768 3771251 398b73 vmlinux.4.0
3023306 429364 347384 3800054 39fbf6 vmlinu
--- Comment #20 from mmitchel at gcc dot gnu dot org 2005-10-31 04:15
---
This is a showstopper; ICE on simple, valid code. We need to resolve what
approach (es) to use to fix this and get it done.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:18
---
Downgraded to P4. If we can fix this great; otherwise, we'll look at it again
for 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-31 04:19 ---
(In reply to comment #7)
> Downgraded to P4. If we can fix this great; otherwise, we'll look at it
> again for 4.2.
It is not like I did not post a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:20
---
This is a serious wrong-code problem; it's a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:23
---
I'm on the fence as to whether to call this P1 or P2. People have really
started to use -ftree-vectorize and it's a major advantage of the more recent
compilers over 3.4.x, so I'd really like to see this fixed. O
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 04:28
---
This will never be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-10-31 04:29
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23155
--- Comment #7 from dannysmith at users dot sourceforge dot net 2005-10-31
04:30 ---
This is an i386 bug, not specific to MS windows target. However, it is only a
problem with -mtune=i386 -mrtd.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:31
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:31
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 04:36
---
So, Jeff, is it your opinion that this is just an inevitable case of
optimizers-aren't-perfect? If so, would you please just close this PR?
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 04:37
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 04:39
---
Leavinga s P2. We should at least look at this, and understand what's wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:40
---
Leaving as P2. I'm only 75% sure this is valid, but we should at least
investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:43
---
I think we should look for some solution to this problem, without reverting the
previous patch. If this problem is amenable to a peephole, let's solve it that
way.
That said, I'm going to downgrade this to P4; if
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 04:45
---
Jan, what's your analysis on this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23303
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:49
---
Do we have any analysis about why the register allocator is doing a worse job?
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #13 from dann at godzilla dot ics dot uci dot edu 2005-10-31
04:50 ---
(In reply to comment #12)
> A more interesting test would be to see the Linux kernel size difference,
There's such a comparison now in comment #8 in PR23153. It confirms the size
increase.
--
http:/
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 04:55
---
I'm going to resolve this as INVALID. If there's a bug here, we need a test
case that shows that inferior code; then, we can reopen this bug.
--
mmitchel at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 04:56
---
Leaving as P2; we should definitely fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23336
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:58
---
Why have we regressed relative to 4.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-31 04:59 ---
Subject: Re: [4.1 Regression] FRE before DCE makes a mess of loads or need to
sink loads
>
>
>
> --- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:58
> ---
> Why have we regressed relat
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 05:00
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:01
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-31 05:02 ---
Here is a C testcase (so that Mark does not lower this to P5):
struct f {};
struct g1 {struct f l;};
static inline void g(struct f a, int i){}
void h(void)
{
struct g1 t;
g(t.l , 1);
}
--
http://gcc.gnu.org/
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:02
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 05:03
---
Dale, would you please attach the C++ testcase for this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 05:05
---
We don't need speculation; we need facts. I'll leave this at P2, in the hopes
that someone will analyze this properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:09
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 05:09
---
Leaving as P2; we should fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23457
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 05:13
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-31 05:13 ---
I decided against committing the patch as obvious.
Anyways the patch was posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01770.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:17
---
I'd like to see this fixed. Is there any throttling we can do here?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:22
---
This patch is OK, assuming no objections within 24 hours.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Testcase:
void abort (void);
int ii;
typedef struct {} raw_spinlock_t;
typedef struct {
raw_spinlock_t raw_lock;
} spinlock_t;
raw_spinlock_t one_raw_spinlock (void)
{
raw_spinlock_t raw_lock;
ii++;
return raw_lock;
}
int main(void)
{
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 05:26 ---
This still fails as of today.
I will repost and retest the patch later today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:28
---
Certainly, the test-case in Comment #1 does depend on libstdc++ at all. Let's
fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 05:36
---
I don't think this PR is, in-and-of-itself, is very interesting, as it's a
1-byte size increase with -O2, which, as has been said, is not aimed at
minimizing code size. So, I'm going to close this PR -- but, leav
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:39
---
Elevating to P1; this is a serious wrong-code regression.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:41
---
Yup, this is a showstoppper.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 05:42
---
Leaving as P2, pending investigation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-10-31 05:46
---
Downgrading to P4. I'd like to see more progress for 4.1, but it's not going
to be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #20 from mmitchel at gcc dot gnu dot org 2005-10-31 05:48
---
This is a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:50
---
This is a showstopper, at least until we analyze it better.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #23 from mmitchel at gcc dot gnu dot org 2005-10-31 05:52
---
Do we have a C/C++ testcase for this problem?
I'm going to leave this as P2 for now, given that we think it's not
language-dependent, and given that we seem close to a fix.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:53
---
We should either fix this, or, at least, figure out why we can't; leaving as
P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:54
---
A bug in the -E -C output is never going to be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:54
---
Leaving as P2; we need to fix this or figure out why we can't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24037
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:56
---
Should this be marked as fixed, or as 4.0-only, given the patch in Comment #8?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24093
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:57
---
Leaving as P2. This really should be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:58
---
I'm not sure whether we want to try to allow this in C++. (I think this is
valid C99, using the flexible array extension, but I'm not certain.) Clearly,
however, ICEing is bad; leaving as P2.
--
http://gcc.g
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-31 06:00
---
This is a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:02
---
I'm marking this as P1, at least until we do some analysis.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-10-31 06:04
---
Altivec is very popular; this is a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:05
---
How broken is -fgcse-sm? Is it broken enough that it should not only be
disabled by default but also hard-wired off on release branches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
201 - 300 of 325 matches
Mail list logo
