--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-13 21:33
---
*** This bug has been marked as a duplicate of 17021 ***
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-13 21:33
---
*** Bug 17980 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-13 21:46
---
I think PR 1259 relates to deficiencies in the compiler,
not the runtime (or at least not this part of the runtime).
This PR refers to a minor possible optimization when defining
an interpreted class; it
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-14 22:47
---
PR 13468: stack trace regression (one patch is on BC branch already)
--
What|Removed |Added
oduct: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-20 18:03
---
My understanding is that other java compilers do use the locale's
default encoding. However, unlike the glibc iconv() converter,
typically javac treats ASCII as equivalent to Latin 1.
--
16902)
--
Summary: automate marking of Class object
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu do
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-25 18:55
---
As a workaround you can put an extra block inside the
instance initializers:
{{ Object foo = ... }}
The bug here seems to be that gcj chains the statements
of each initializer block together when making
mmary: gcj has wrong type for itable
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu do
--
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla
regression] primitive array optimization is gone
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-28 17:14
---
I think we'll still want a flag allowing the user to disable verification.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14781
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-28 17:14
---
FYI, not verifying in the compiler is somewhat tricky since
the compiler relies on the verifier to create type maps it
uses later on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15735
--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-28 18:20
---
Nobody is planning to add backward compatibility code here.
The exception was added to the 1.4 verifier because it wasn't
possible to correctly compile valid java programs without it.
So, targeting 1.4
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-02 18:55
---
Do you have some sample code or something?
I tend to suspect your code, simply for the reason
that GObject is not part of libgcj.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18278
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-08
06:30 ---
I'm testing a patch to emit those constants defined
in the class itself. Inherited not constants are
not emitted; this is harder and related to PR 15411
(in both cases we would have to read other
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-08
22:17 ---
The code says:
while (br.read(charBuff,0,fileLength) != -1)
bw.write(charBuff,0,fileLength);
There is no guarantee that read() will fill the buffer.
If you see a partial read, you will then write a
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-09
22:11 ---
I downloaded the test case and modified it to print the
number of characters it read. I can confirm that for me it
does in fact loop:
opsy. gij TestGcj.IoTest ../demo/buildlog.txt Out.txt
fileLength
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-09
22:18 ---
Actually we have Package.isCompatibleWith, what we don't
have is any version setting on java.lang or other built-in
packages.
Strangely the BEA JRE dies on this:
opsy. j
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-16
20:02 ---
I tried reproducing this on x86 FC2.
I did:
rm i686-pc-linux-gnu/libjava/{config.cache,Makefile}
make CFLAGS_FOR_TARGET='-g -O2 ' configure-target-libjava
Then:
cd i686-pc-linux-gnu/libja
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-25
03:25 ---
Oops, I wasn't aware that the locks code was using finalizers.
We had to make special consideration in the reference code for
String.intern; we can do something similar for locks.
This is pretty importa
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-25
03:26 ---
18266: low-level bug in Reference code; this is used by
many real applications
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||17574
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-27
01:21 ---
I tried this with current cvs head and it worked fine.
--
What|Removed |Added
--
Bug 17915 depends on bug 17963, which changed state.
Bug 17963 Summary: [4.0 Regression] Compiling a .jar files fails when files
within .jar are in a different order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17963
What|Old Value |New Value
---
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-27
01:26 ---
I downloaded the files, unzipped, and tried with the
current cvs gcj. It compiled both .jar files without
error.
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-27
01:32 ---
The only missing option here is "gcj -cp foo".
cvs head gcj accepts "-classpath foo" (not sure if 3.x did).
gij accepts both short and long forms of options, and
understands
--- Additional Comments From tromey at gcc dot gnu dot org 2004-11-29
20:17 ---
If the GC headers that we include rely on the defines in
the GC's config.h, then that would explain the problem.
We don't actually need PACKAGE_NAME and friends, I think.
One fix would be to si
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-01
21:09 ---
I'm testing a patch
--
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-01
21:40 ---
How curious. Apparently the JDK unwraps the return result of
a JNI method that returns a JNI weak reference.
I think it is too late to implement this for GCC 4.0 (unless the
commit rules change again
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-01
21:59 ---
Most of these cases work fine for me.
However, this one fails:
opsy. gcj -o Z --classpath=B.jar:A.jar:. --main=ProcessorOptimizer.Main X.jar
A.jar B.jar
java/security/SecureRandom.java:0: internal compiler
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-01
22:46 ---
Fixed by the BC branch merge
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-02
16:38 ---
Fix checked in.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-02
18:11 ---
I'm testing a patch
--
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-02
18:25 ---
I'm changing the title to reflect that it is a front end
bug and not a class generation bug. The code should not be
accepted.
--
What|Removed |
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-02
19:44 ---
Fix checked in
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
19:33 ---
Fix checked in
--
What|Removed |Added
Status|NEW
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
23:25 ---
I've looked into this a little.
Apparently we are getting to this line in
resolve_inner_class:
local_super = do_resolve_class (NULL, local_super, NULL, NULL);
with local_super:
(gd
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-03
23:33 ---
Andrew fixed this.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-04
00:28 ---
I looked into this today.
When compiling to .o (or with --syntax-only), the
"System.out" reference is wrapped in a compound_expr
whose LHS initializes the System class.
I'm
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-06
15:33 ---
Fix checked in, will appear in gcc 4.0
--
What|Removed |Added
Status|ASSIGNED
--
Bug 13607 depends on bug 14853, which changed state.
Bug 14853 Summary: [3.3/3.4/4.0 Regression] Assignment to final field permitted
when compiling to native
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
What|Old Value |New Value
---
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-06
18:34 ---
The patch should probably apply as-is to 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-07
17:07 ---
I'm building this for 3.4 right now.
If it works ok I will submit it.
I don't plan to try it for 3.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14853
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-07
19:58 ---
I compiled A.java with 'gcj -C A.java', downloaded C.class, and ran
"gij C" without problems.
I'm using a recent-ish cvs head.
If the problem is in the other .class files
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-07
20:08 ---
I was able to reproduce this by compiling A.java with jikes.
libgcj should find the field A$1.instance as inherited from
A, but it does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18868
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-07
20:20 ---
The bug is that libgcj is not searching the superinterfaces
of A$1. The fix is to use code similar to that in the method
case in _Jv_linker::resolve_pool_entry. (This need only be
done for static fields
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-13
21:40 ---
Note that -findirect-dispatch doesn't fully work with
the .java front end. This bug is still useful to have
in bugzilla, but it isn't a priority for 4.0; for that
release we documented this as n
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-14
19:26 ---
This also works on x86-linux.
One way I think it could fail on Windows is if the
zip contains extended time stamps and we try to load
some locale data and can't find it. This might cause
the fa
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-14
20:17 ---
FYI, this will only work with the new verifier,
which is only available via -findirect-dispatch.
The new verifier doesn't yet work with the old ABI, AFAIK.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-14
20:16 ---
I got this to fail with yesterday's cvs head.
Removing the "-O2" is a workaround.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
--- Comment #7 from tromey at gcc dot gnu dot org 2006-10-21 21:49 ---
I'm going to close this as fixed.
Thanks Gerald.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29594
--- Comment #3 from tromey at gcc dot gnu dot org 2006-10-26 17:58 ---
Instead of directly calling accept we could select or poll on the fd.
This would let us have a timeout or an interrupt or something.
For all I know poll would react more gracefully to another thread
closing the fd
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-01 22:06 ---
Fixed on the branch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-05 21:15 ---
Subject: Bug 29495
Author: tromey
Date: Tue Dec 5 21:15:34 2006
New Revision: 119557
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119557
Log:
gcc/java
PR java/29495:
* jcf
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot
|dot org
--- Comment #6 from tromey at gcc dot gnu dot org 2006-12-06 19:35 ---
Subject: Bug 24938
Author: tromey
Date: Wed Dec 6 19:35:05 2006
New Revision: 119593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119593
Log:
PR java/24938:
* sources.am, Mak
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-07 17:19 ---
Fixed on ecj branch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-07 18:37 ---
Nothing to do -- not sure why I didn't close it earlier.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-08 00:15 ---
Also we appear to incorrect create the annotation data
structure for one of the methods.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-08 01:13 ---
I needed this to see correct output.
There's still some oddity where main sorts before barf in the output,
I haven't looked at that.
--- pp.java.~1~ 2006-12-05 11:49:25.0 -0700
+++ pp.java 200
--- Comment #6 from tromey at gcc dot gnu dot org 2006-12-08 01:15 ---
Oh, I see. It is just that we need:
Arrays.sort(methods, myCollator);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30076
--- Comment #7 from tromey at gcc dot gnu dot org 2006-12-08 01:19 ---
Subject: Bug 30076
Author: tromey
Date: Fri Dec 8 01:19:17 2006
New Revision: 119644
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119644
Log:
PR libgcj/30076:
* defineclass.cc (rea
--- Comment #8 from tromey at gcc dot gnu dot org 2006-12-08 01:26 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-08 20:30 ---
Subject: Bug 30110
Author: tromey
Date: Fri Dec 8 20:30:14 2006
New Revision: 119664
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119664
Log:
2006-12-08 Ben Konrath <[EMAIL PROTECTED]&g
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-08 20:33 ---
Subject: Bug 30110
Author: tromey
Date: Fri Dec 8 20:33:22 2006
New Revision: 119665
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119665
Log:
2006-12-08 Ben Konrath <[EMAIL PROTECTED]&g
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-08 20:34 ---
I checked it in to 4.2 and to the gcj-eclipse-merge-branch.
The latter should be merged to trunk reasonably soon.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||28067
AssignedTo|unassigned at gcc dot gnu |tromey at gcc
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||28067
AssignedTo|unassigned at gcc dot gnu |tromey at gcc
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-12 20:30 ---
A stack trace would help here ... can you install debug info or something
and try again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-26 00:24 ---
I think the rationale here is just that, if -MP added the main source
file as a phony target, then 'make' would not do anything at all if the
main file was missing. But, that result seems wrong -- f
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-26 00:33 ---
This is a bit weird but it is the documented behavior of -MMD.
To get a different target you must use -MT or -MQ.
My first reaction is that changing this may be unfriendly
(we don't know who, if anyone, is relyi
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-26 00:37 ---
FWIW I do not see this bug with the fedora core 6 gcc:
mopsy. gcc --version
gcc (GCC) 4.1.1 20061011 (Red Hat 4.1.1-30)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-26 20:55 ---
FWIW making the gcc driver work properly here is not easy.
gcj reads a spec file with internal options in it.
These are required for the proper operation of jc1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-27 11:14 ---
The reason we did this is that, when we wrote libgcj, we wanted to
be able to control various abi-changing things via command-line
arguments. And, the best place to do much of the checking was in
the libgcj
--- Comment #8 from tromey at gcc dot gnu dot org 2006-12-27 21:43 ---
I looked at this a bit.
The basic problem resembles bug #14438 in a way.
The source code here has an unterminated "call" to a function-like
macro. cpp thinks all the subsequent #define directives
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-27 22:08 ---
FWIW this doesn't entirely look like a bug to me.
The code is reaching a gcc_unreachable() statement,
so this is more along the lines of a properly
functioning internal check.
--
http://gcc.gnu.org/bug
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 00:59 ---
The followup patch here:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00868.html
.. looked reasonable to me (although the ChangeLog entry
is overly verbose). However I can't approve it.
--
tromey at gc
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-28 01:28 ---
Also 6.10.8.4 says that various other macros, like __DATE__,
shall not be the subject of #define or #undef. Currently we
warn in these cases but perhaps we ought to have a pedwarn instead.
I have a patch for the
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-28 01:34 ---
This seems reasonable enough to me, offhand.
I suppose and are translated
because they may be visible as part of error reporting,
but this doesn't seem super compelling to me.
I think the fix for this is a c
--- Comment #10 from tromey at gcc dot gnu dot org 2006-12-28 01:38 ---
Is this patch just waiting for someone to commit it?
The paperwork is all done?
If so please respond and I will check it in.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 04:22 ---
FWIW what happens here is that 'foo;' is turned into
'-> >>;' by cpp; then the second error is emitted by the
C parser. You can easily see this by comparing the -E output
against t
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 04:49 ---
This is a bug against a very old release for code that no longer
exists. Is it ok to give up and close it as invalid?
The bug management page is not clear on when old bugs can be closed;
I think this one should be
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 18:45 ---
Subject: Bug 30001
Author: tromey
Date: Thu Dec 28 18:45:48 2006
New Revision: 120245
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120245
Log:
PR preprocessor/30001:
* c
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 18:47 ---
I checked in the fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tromey at gcc dot gnu dot org 2006-12-28 19:11 ---
This isn't really a gcc bug per se, so I am closing it.
If someone wants to implement one or all of these on a branch,
that is still fine.
--
tromey at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 19:12 ---
This option no longer exists and 3.3 is no longer maintained.
So, I am closing this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tromey at gcc dot gnu dot org 2006-12-29 02:54 ---
I am testing a patch for this.
It pedwarns on '#foo' in an expression, and also when #assert or
#unassert is used. It also warns about these when -Wdeprecated
is given.
--
tromey at gcc dot gnu dot o
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-29 03:28 ---
This happens because destringize_and_run calls cpp_push_buffer.
The new buffer has a non-null 'prev'; do_pragma_system_header
checks for prev==NULL to determine whether the directive is
in the primary s
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-29 04:29 ---
I think this will also occur for _Pragma("once")
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-29 04:30 ---
I think this same problem will occur with #include_next
and #pragma once. cpp doesn't currently seem to differentiate between
the PCH case and other kinds of preprocessing.
--
tromey at gcc dot gnu do
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-29 07:43 ---
I looked at this a bit tonight.
It is straightforward to remove -finput-charset from the second
invocation of cc1 (needed several places -- gcc.c but also the
c++ and objc lang-specs).
I think this approach fails
--- Comment #25 from tromey at gcc dot gnu dot org 2006-12-29 07:58 ---
FWIW I've been looking at this area for PR 29966.
I don't see how overflow checking could be added to
_cpp_lex_direct. However I did end up adding an
assertion to _cpp_lex_token, to try to expos
: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30330
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-30 23:11 ---
FWIW my initial attempt here, namely inserting %http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21521
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-01 00:34 ---
Sorry, I forgot all about that.
It would be convenient if the manual had an @optindex for both
spellings. That way I could use the index to jump to the docs for any
option, not just non-default options
--- Comment #13 from tromey at gcc dot gnu dot org 2007-01-03 19:17 ---
I'm not sure whether the updated patch can be committed without
another review. I'll try to find out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13676
1301 - 1400 of 1570 matches
Mail list logo
