--- Comment #1 from mckinlay at redhat dot com 2006-04-04 19:52 ---
I couldn't reproduce this when installing Subclipse, but after installing it
and subsequently trying to disable it, I reproducably get the following
--- Comment #2 from mckinlay at redhat dot com 2006-04-04 20:34 ---
The difference between Sun's and Classpath's implementation appears to be that
Classpath will check for Concurrent Modification on both hasNext() and next()
calls, while Sun's implementation only chec
--- Comment #5 from mckinlay at redhat dot com 2006-04-05 15:19 ---
(In reply to comment #4)
> I would argue that Sun's implementation is correct in this case in the
> sense that hasNext() doesn't actually modify anything, only next() does.
Yeah, I agree - although
--
mckinlay at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com
|dot org
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 ---
*** This bug has been marked as a duplicate of 27028 ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
--- Comment #6 from mckinlay at redhat dot com 2006-04-05 15:22 ---
*** Bug 24632 has been marked as a duplicate of this bug. ***
--
mckinlay at redhat dot com changed:
What|Removed |Added
--- Comment #8 from mckinlay at redhat dot com 2006-04-05 18:43 ---
Fix checked in to Classpath HEAD and gcc-4_1_branch
--
mckinlay at redhat dot com changed:
What|Removed |Added
--- Comment #2 from mckinlay at redhat dot com 2006-04-06 20:08 ---
I'm not sure I follow this. create() does not get called until the socket is
bound. Don't we know at that point whether we're binding to an IPV4 or IPV6
address?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
--- Additional Comments From mckinlay at redhat dot com 2005-04-20 15:56
---
Ziga, please let us know as soon as your FSF paperwork clears. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20504
--- Additional Comments From mckinlay at redhat dot com 2005-05-02 16:44
---
It sounds like this is just a matter of testing that it really does work now.
Pinskia: If you could test/post a patch, that would be great.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21325
--- Additional Comments From mckinlay at redhat dot com 2005-05-03 21:57
---
There is already a ChangeLog entry with the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21372
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21557
--- Additional Comments From mckinlay at redhat dot com 2005-05-14 00:43
---
Fix checked in.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From mckinlay at redhat dot com 2005-05-19 20:30
---
Yeah, its probably pointless backporting anything else this late in the 3.4
cycle, especially now that 4.0 is out. I'm closing the PR.
--
What|Removed |
Summary: String.substring sharing heuristic should be improved
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat
--- Additional Comments From mckinlay at redhat dot com 2005-05-30 15:35
---
Its easy to fix this for natFileChannelImpl.cc.
For natFilePosix.cc it is not so simple - is there a portable alternative to
realpath() that does not require the use of MAXPATHLEN / PATH_MAX
--- Additional Comments From mckinlay at redhat dot com 2005-06-09 00:56
---
I've checked this in to HEAD and Classpath cvs. Strictly speaking, it shouldn't
go into GCC 4.0 as its an ABI change and our no-C++-abi-incompatible-changes
policy is still in place. Do you need
--- Additional Comments From mckinlay at redhat dot com 2005-06-15 21:43
---
I'm testing a fix. This is a different problem to 18131.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697
--- Additional Comments From mckinlay at redhat dot com 2005-06-15 21:44
---
Err, 18119 I mean.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20697
--- Additional Comments From mckinlay at redhat dot com 2005-06-15 22:07
---
*** This bug has been marked as a duplicate of 20697 ***
--
What|Removed |Added
--- Additional Comments From mckinlay at redhat dot com 2005-06-15 22:07
---
*** Bug 22060 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From mckinlay at redhat dot com 2005-06-17 22:59
---
Confirmed
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever
--- Additional Comments From mckinlay at redhat dot com 2005-06-18 01:49
---
GCJ actually has the resolution order correct here. The problem is that a.A.B is
not visible from b.C, because its a private class. Instead of an error, however,
GCJ needs to resolve to the visible class b.B
--- Additional Comments From mckinlay at redhat dot com 2005-06-18 01:50
---
I'm testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674
--- Additional Comments From mckinlay at redhat dot com 2005-06-18 01:51
---
I'm testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21045
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22128
--- Additional Comments From mckinlay at redhat dot com 2005-01-05 23:53
---
I narrowed this down to a small test case. The following code will cause the
crash when compiled to bytecode using Sun's javac 1.5.0 (but not when
byte-compiled with gcj or ecj).
public class PR
0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
--- Additional Comments From mckinlay at redhat dot com 2005-01-06 02:19
---
gij also fails to execute this bytecode:
$ gij Test
Exception in thread "main" java.lang.IncompatibleClassChangeError: field
Test.foo was not found.
at Test.main (Test.java:5)
--
http://g
--- Additional Comments From mckinlay at redhat dot com 2005-01-10 19:16
---
Thanks for the test case.
A workaround for this, using GCC HEAD, is to use the --indirect-dispatch compile
option. This will use the "new verifier" code which does not have this bug.
--
--- Additional Comments From mckinlay at redhat dot com 2005-01-25 15:12
---
Here's a test case for this bug, copied from PR18931. This will fail when
compiling from bytecode produced by Sun's javac, but not from bytecode produced
by gcj or ecj.
public class PR19505 {
--- Additional Comments From mckinlay at redhat dot com 2005-01-25 15:56
---
Using the latest GCC HEAD awt code, I can no longer reproduce this problem.
Sweet! I'm closing the PR.
--
What|Removed |
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-01-
--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:26
---
This is probably due to the 100-byte character conversion buffer in
java/io/PrintStream.java. The buffer size could be increased if it will improve
network efficiency. Any idea what size the Sun implementation
--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:30
---
I've put a test case for this in mauve:
gnu/testlet/java/util/Date/getTimezoneOffset.java
This test case also exposes some problems with libgcj's underlying TimeZone
data.
This patch looks corre
--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:37
---
Turns out its already fixed in GNU Classpath. Re-syncing with their version.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19649
rated
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gnu do
--
What|Removed |Added
OtherBugsDependingO||16990
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19682
--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:45
---
Fixed
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 16990 depends on bug 19649, which changed state.
Bug 19649 Summary: java.util.Date.getTimezoneOffset returns negated output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19649
What|Old Value |New Value
--
--- Additional Comments From mckinlay at redhat dot com 2005-01-29 00:48
---
This appears to be fixed:
$ TZ='Europe/Moscow' gij TZMain
Sat Jan 29 03:46:38 GMT+03:00 2005
$ TZ='Europe/Kaliningrad' gij TZMain
Sat Jan 29 02:47:07 GMT+02:00 2005
--
--
Bug 16990 depends on bug 11941, which changed state.
Bug 11941 Summary: gcj handles timezones wrongly with new Date().toString()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11941
What|Old Value |New Value
-
--- Additional Comments From mckinlay at redhat dot com 2005-02-03 05:27
---
Should we have SHA-192, SHA-384, etc as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19728
spatch
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
--- Additional Comments From mckinlay at redhat dot com 2005-02-09 04:11
---
Note that TestProxy is failing too, which does seem to indicate a problem with
ffi closures.
boehm-gc does have code to call mprotect() on its heap (see PROTECT/UNPROTECT in
os_dep.c), but it isn't
--- Additional Comments From mckinlay at redhat dot com 2005-02-11 20:56
---
19907 is a dupe of this.
*** This bug has been marked as a duplicate of 19907 ***
--
What|Removed |Added
--- Additional Comments From mckinlay at redhat dot com 2005-02-11 20:56
---
*** Bug 19834 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From mckinlay at redhat dot com 2004-08-18 15:55 ---
Fix checked in.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 17:44 ---
The patch will need to be updated for the new stack trace infrastructure,
because the interface to stack traces has changed. In particular, the
gnu.gcj.runtime.StackTrace class is no longer supported.
Either a
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 17:45 ---
Actually using the native API is probably the better option, since having a
public stack trace API in Java is likely a security problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 17:52 ---
Do we really want to fix this?
The "buggy" behaviour actually seems better here because it more closely matches
what other Java compilers do and seems to have resulted in less complaints from
user
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 18:10 ---
Forget what I said, Tom is right. I just tested this again, and javac from JDK
1.5 does indeed use the Locale setting to determine the default encoding.
Further more, javac does appear to distinguish between
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 19:07 ---
?? Pinskia: are you sure? This should be fixed already on mainline. Here's the
output I get with 4.0.0 20041019:
$ gij CalendarTest2
Today: Wednesday, 2004-10-20 [294] 15:05:28.0425
Friday, 2004-10-01 [27
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 19:36 ---
I've added a regression test based on this test case, to mauve's
gnu.testlet.java.util.Calendar.set
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18087
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 20:49 ---
For the memcpy() thing, in the error given we seem to be relocating something to
the exact same position. In this case the memcpy() should be harmless. But,
maybe it is possible to get real overlapping
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 21:38 ---
Fix checked in.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 17574 depends on bug 15575, which changed state.
Bug 15575 Summary: HAVE_LANGINFO_CODESET never defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15575
What|Old Value |New Value
--
--- Additional Comments From mckinlay at redhat dot com 2004-10-20 21:41 ---
Removing PR 14664 because its fixed on the 4.0 trunk.
--
What|Removed |Added
BugsThisDependsOn
--- Additional Comments From mckinlay at redhat dot com 2004-11-02 16:11 ---
Would it make more sense for GCJ to accept ':' instead of/as well as ';' on
mingw? Perhaps with some logic to distinguish a drive-letter ':'? The Makefiles
are sure ugly now wit
--- Additional Comments From mckinlay at redhat dot com 2004-11-04 18:46 ---
Here's my thoughts about this:
- This optimization only ever worked for source compilation. Bytecode compilers
always emit array initializers as code, so for byte compilation it makes no
difference.
- I
tions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckinlay at redhat dot com
CC: gcc-bugs at gcc dot gn
--
What|Removed |Added
OtherBugsDependingO||12725
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18377
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18377
--- Additional Comments From mckinlay at redhat dot com 2004-11-29 15:48
---
I'm investigating...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18699
--- Additional Comments From mckinlay at redhat dot com 2004-11-30 00:39
---
Something strange is going on here. I have reverted the boehm-gc config patches
for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18699
--- Additional Comments From mckinlay at redhat dot com 2004-12-10 05:47
---
meth->index for an interface method should contain the IDT dispatch index for
that method, which allows us to use fast interface dispatch
(_Jv_LookupInterfaceMethodIdx) for Method.invoke() calls. Unfortunat
101 - 166 of 166 matches
Mail list logo
