--- Comment #3 from tromey at gcc dot gnu dot org 2006-02-10 19:54 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #10 from tromey at gcc dot gnu dot org 2006-02-10 19:54 ---
Forgot to mark as fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-02-11 00:41 ---
Subject: Bug 26204
Author: tromey
Date: Sat Feb 11 00:41:08 2006
New Revision: 110866
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110866
Log:
PR java/26204:
* jcf
--- Comment #5 from tromey at gcc dot gnu dot org 2006-02-11 00:42 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from tromey at gcc dot gnu dot org 2006-02-13 22:25 ---
Marking as fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from tromey at gcc dot gnu dot org 2006-02-14 22:29 ---
I couldn't find any documentation for this format, so
interoperation is not easily possible.
Also this page (see bottom) indicates that we ought to try
loading the prefs provider via the service factory code:
--- Comment #4 from tromey at gcc dot gnu dot org 2006-02-28 20:53 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-01 16:01 ---
Subject: Bug 24321
Author: tromey
Date: Wed Mar 1 16:01:34 2006
New Revision: 111603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111603
Log:
PR java/24321:
* testsuite/libj
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-01 16:29 ---
Fix checked in to trunk.
This may be a good 4.1.1 candidate.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-01 17:13 ---
That format is used for exporting preferences to a file.
It turns out they use a variant of that for writing the
preferences to the preference store. However, how locking is
handled is undocumented. So
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-06 17:08 ---
You can read about the java programming language's requirements
for floating point here:
http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3
Relevant quote:
In particular, the
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 15:16 ---
Now I think the idea in comment #3 is incorrect.
I looked at implementing it today, and I realized that
it will also cause a super() constructor call to
throw an exception.
The idea in comment #1 may still work
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 16:14 ---
It would be helpful to have a stack trace for the exception.
Or, Anthony, if you know more about the problem, could you update
this PR?
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 16:16 ---
Does this stop the build? I think this error can safely be ignored.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 16:37 ---
I'm testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 16:58 ---
3.4.x is closed, we won't be putting any bug fixes on that branch.
(I think the next 3.4.x release will be the last one ever.)
This bug does seem to appear on the 4.0 branch.
I think I'll check in your
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 17:07 ---
Subject: Bug 26351
Author: tromey
Date: Tue Mar 7 17:07:37 2006
New Revision: 111814
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111814
Log:
2006-03-07 fexx <[EMAIL PROTECTED]>
P
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-07 17:08 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 18:16 ---
I think this was just fixed by David Daney:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111815
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26073
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-07 18:52 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 21:34 ---
Subject: Bug 26103
Author: tromey
Date: Tue Mar 7 21:34:46 2006
New Revision: 111819
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111819
Log:
PR libgcj/26103:
* java/lang/ClassLoa
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 21:39 ---
Subject: Bug 26103
Author: tromey
Date: Tue Mar 7 21:39:44 2006
New Revision: 111820
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111820
Log:
PR libgcj/26103:
* java/lang/ClassLoa
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-07 21:41 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-07 22:41 ---
I believe this was fixed a while back.
The test cases work for me with 4.1.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-07 22:44 ---
Testing a patch.
I think this bug report is a bit wrong, in that we don't actually
need to link the JNI library into libgcj. loadLibrary seems appropriate
here, particularly given that this code is seldom
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-07 22:49 ---
I tried this test case with my 4.1 build and it seemed to work fine.
opsy. gij HServer &
[1] 21044
opsy. gij HClient
READ: 224
READ: 12
opsy. java.net.SocketException: Socket Closed
at HServer$1.run (HServer.
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-07 23:00 ---
Defining these types seems ok to me.
It would be nice if there were front end documentation
explaining that front ends are required to, though.
FWIW Alexandre Oliva has a patch to bug 8620
the "other way&q
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26495
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-08 00:37 ---
I looked and as far as I can see, this bug is fixed in 4.1.
PersistentByteMap.close now throws IOException.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-08 00:54 ---
Actually, Robin, could you send your current patch for this?
It seems like we should simply put it in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 15:03 ---
Subject: Bug 24183
Author: tromey
Date: Wed Mar 8 15:03:48 2006
New Revision: 111844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111844
Log:
PR libgcj/24183:
* native/jni/xmlj/Mak
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-08 15:05 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 16:30 ---
Isn't this fixed in 4.1?
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-08 19:27 ---
I've been looking into this a bit.
The current problem I see is that the heavyweight lock stuff
relies on the GC. This won't interact well with the current
code in natReference.cc, as those data structur
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-09 01:12 ---
I'm closing since it is fixed in the current release.
I haven't found the precise fix so I don't know if a 4.0.x
backport is possible.
--
tromey at gcc dot gnu dot org changed:
W
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-09 19:02 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-09 19:17 ---
Fair enough. I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-09 20:22 ---
Subject: Bug 24461
Author: tromey
Date: Thu Mar 9 20:21:58 2006
New Revision: 111870
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111870
Log:
PR libgcj/24461:
* java/
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-09 20:25 ---
Subject: Bug 24461
Author: tromey
Date: Thu Mar 9 20:25:23 2006
New Revision: 111871
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111871
Log:
PR libgcj/24461:
* java/
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-09 20:27 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #13 from tromey at gcc dot gnu dot org 2006-03-10 00:39 ---
Subject: Bug 23495
Author: tromey
Date: Fri Mar 10 00:39:49 2006
New Revision: 111919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111919
Log:
PR libgcj/23495:
* java/lang/natS
--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-10 00:48 ---
I checked in a patch using memcpy and memcmp.
This didn't yield as dramatic a speedup for me, but did do ok.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-10 23:14 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-11 01:40 ---
Mark's problem appears to be a bytecode generation bug.
We are generating:
6: invokespecial #65=
But this is incorrect as you cannot invoke an interface method
with invokespecial. And, super.foo() should
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-13 17:10 ---
Created an attachment (id=11043)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11043&action=view)
reduced test case
I'm attaching a reduced test case.
If you remove one of the intermediate classes
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-13 17:12 ---
I added a main to the reduced test case:
public static void main(String[] args)
{
SwingFramePeer s = new SwingFramePeer();
s.setBounds();
}
With this I can almost reproduce the original bug:
opsy
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-13 19:07 ---
The bug here is that gcj implements method inheritance incorrectly.
In particular it does not consider SwingWindowPeer.setBounds
as a candidate method for the super.setBounds() call, because it
has no notion that
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-15 00:20 ---
I looked at this a bit. First, IMode has a method -- this is a bug,
as it is not needed.
Second, I don't understand why, but we leave a slot in the itable for
. There doesn't seem to be any reason to d
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-15 00:25 ---
I see something else strange in here.
maybe_yank_clinit() does nothing unless we are compiling to bytecode.
I can't see why that would be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26638
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-15 05:26 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-15 17:17 ---
Despite what the original report says, we don't really want to
resolve all entries when compiling.
Also it would be best to avoid any kind of synchronization at all.
One idea would be to 'or' the arg
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-15 18:29 ---
Subject: Bug 26390
Author: tromey
Date: Wed Mar 15 18:29:44 2006
New Revision: 112093
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112093
Log:
gcc/java
PR java/26390:
*
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-15 18:31 ---
Oops -- that was the wrong PR number in that patch.
That commit was for PR 26638.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-15 18:45 ---
Subject: Bug 26638
Author: tromey
Date: Wed Mar 15 18:45:02 2006
New Revision: 112094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112094
Log:
Correctly reference PR java/26638 in ChangeLogs
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-15 18:45 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-15 20:19 ---
This was fixed on the trunk by:
2006-02-15 Andrew Haley <[EMAIL PROTECTED]>
* class.c (GEN_TABLE): Don't pushdecl *_SYMS_DECL here.
(make_class_data): pushdecl_top_level TYPE_OTABL
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-15 20:26 ---
Now I think we don't need to do anything here.
We already handle the common cases.
For instance, if the target is an interface we will use
the IDT to do this test. This is reasonably fast.
Also if both class
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-16 00:19 ---
I'm not certain that this should be fixed in Classpath.
After all, Classpath doesn't use svn.
I have a fix for libgcj which I will check in soon.
--
tromey at gcc dot gnu dot org changed:
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-16 01:54 ---
Subject: Bug 26688
Author: tromey
Date: Thu Mar 16 01:54:51 2006
New Revision: 112115
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112115
Log:
PR libgcj/26688:
* lib/Makefile.in:
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-16 01:58 ---
Subject: Bug 26688
Author: tromey
Date: Thu Mar 16 01:58:38 2006
New Revision: 112116
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112116
Log:
PR libgcj/26688:
* lib/Makefile.in:
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-16 01:59 ---
I fixed this in GCC svn.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-16 18:19 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-16 19:08 ---
Subject: Bug 26706
Author: tromey
Date: Thu Mar 16 19:08:07 2006
New Revision: 112142
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112142
Log:
PR libgcj/26706:
* aclocal.m4, c
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-16 19:12 ---
Subject: Bug 26706
Author: tromey
Date: Thu Mar 16 19:12:29 2006
New Revision: 112143
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112143
Log:
PR libgcj/26706:
* aclocal.m4, c
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-16 19:15 ---
I checked in the fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-17 18:01 ---
The bug here is that the code that handles assignments
requiring an accessor method does not understand that
a constant might be subject to a narrowing constant conversion.
Hence it does not (e.g.) convert '
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-17 18:06 ---
One potential fix is to call try_builtin_assignconv
in nested_field_access_fix or the like.
I haven't tried this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26720
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-27 18:29 ---
The classpath import won't happen for the 4.1.x branch.
However, a workaround could be applied locally in Currency (or wherever)
as long as it doesn't change the ABI.
--
tromey at gcc dot gnu dot o
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-27 18:36 ---
I'll handle this when I remove fastjar.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-27 18:43 ---
The error appears to be intentional:
jint field_offset = field->u.boffset;
if (field_offset > 0x)
throw new java::lang::VirtualMachineError;
However, I don't know what p
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-27 22:03 ---
I was able to reproduce this with svn head on a ppc32 build.
A ppc64 build did not show this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26042
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-28 01:14 ---
One curiosity I noticed while debugging is that in layout_type,
class Two has size 128 (in bits). This value is incorrect.
Once we reach the code to compute the GC descriptor, the
size is 192.
--
http
ummary: re-merging java.util.zip
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: tromey at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://g
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-28 19:04 ---
I checked in the fix to svn head.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-28 19:05 ---
Subject: Bug 26441
Author: tromey
Date: Tue Mar 28 19:05:21 2006
New Revision: 112465
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112465
Log:
Correcting PR number in ChangeLog:
PR libg
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
Created an attachment (id=11143)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11143&action=view)
initial patch
This patch mostly fixes the problem.
However it is missing some minor bits for windows.
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
I'm handling this.
See the patch attached to PR 13671.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 15:12 ---
The first time we lay out the type, we have the fields reversed.
See parse.y:java_reorder_fields. I don't know why this happens.
(We construct the field list in reverse order, presumably for
efficiency. Wh
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-29 16:32 ---
Subject: Bug 26390
Author: tromey
Date: Wed Mar 29 16:31:53 2006
New Revision: 112499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112499
Log:
gcc/java
PR java/26390:
*
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-29 16:36 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 16:44 ---
Note that we need more mauve tests in this area before fixing the problem.
The current tests don't catch the bug(s).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26910
--
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 #5 from tromey at gcc dot gnu dot org 2006-03-29 17:52 ---
I now agree with comment #4.
I don't think this is a bug.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 18:12 ---
Things look even worse with svn head (4.2 atm)...
either with gij or precompiled, the test case shows
invocations about an order of magnitude slower than the JDK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-29 19:43 ---
There are 2 parts to this bug.
First, there's no reason to build tools.zip in the gcj build (yet).
Second, upstream classpath should pass an explicit -encoding when
invoking the java compiler.
I'm workin
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-29 20:22 ---
In order to do this we should avoid building tools.zip
and instead directly build executables.
(If we need a java archive for some reason, it should be a
jar, anyway.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-29 21:33 ---
Subject: Bug 26901
Author: tromey
Date: Wed Mar 29 21:33:08 2006
New Revision: 112510
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112510
Log:
PR gcc/26901:
* Makefile.in:
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-29 21:42 ---
Fix checked in, please give it a try.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-29 21:45 ---
This was fixed by the patch for PR 26901.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-29 21:48 ---
Really mark as fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tromey at gcc dot gnu dot org 2006-03-29 22:39 ---
I tried this today with svn head.
The test program still prints 'false' no matter how I run it:
gij, compiled, or compiled with the BC ABI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20044
--- Comment #10 from tromey at gcc dot gnu dot org 2006-03-30 16:39 ---
Subject: Bug 26042
Author: tromey
Date: Thu Mar 30 16:39:17 2006
New Revision: 112540
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112540
Log:
gcc/java
PR java/26042:
*
--- Comment #11 from tromey at gcc dot gnu dot org 2006-03-30 16:47 ---
Subject: Bug 26042
Author: tromey
Date: Thu Mar 30 16:47:23 2006
New Revision: 112541
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112541
Log:
gcc/java
PR java/26042:
*
--- Comment #12 from tromey at gcc dot gnu dot org 2006-03-30 16:49 ---
I checked the fix into the 4.1 branch and the trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-31 23:26 ---
I wrote a little script to print the amount of time taken for each
line of 'make' output.
This tends to confirm that installing the headers is very slow.
One other difference from 'make install-ex
1001 - 1100 of 1570 matches
Mail list logo
