--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:47 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #8 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #6 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #8 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #13 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-09 20:48 ---
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks
--
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 #2 from tromey at gcc dot gnu dot org 2007-01-09 22:05 ---
We no longer run jacks on svn trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-10 01:43 ---
How did you configure?
Did you use 'make -j'?
Is there anything else we should know?
There's not enough info in this report to do anything useful, I'm afraid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30419
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-08 19:53 ---
What's the status of this?
The Google assignment situation has been resolved, so I think
the patch submission can move forward...
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-08 01:14 ---
This patch seems fairly reasonable to me, though not perfect.
It will reset errno if stat() fails, which, while probably not
fatal, is still a bit troubling.
--
tromey at gcc dot gnu dot org changed
--- Comment #8 from tromey at gcc dot gnu dot org 2007-01-08 01:21 ---
What is the status of this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
--
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
--
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
--
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
--
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
--
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 #2 from tromey at gcc dot gnu dot org 2007-01-08 01:36 ---
I've submitted a patch.
As explained in the message, I think we should just document
the current behavior, not change it.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-08 01:41 ---
Confirmed with svn trunk.
You don't have to worry about the triplets in this case.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-08 01:48 ---
The -MT documentation is in error, that is PR 15185.
I didn't find this text confusing since, I suppose, I'm used to
basename referring to what the basename(1) program does.
--
tromey at gcc dot gnu dot org
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-08 01:54 ---
Confirmed.
I'm inclined to agree that we should disallow -MG in this situation.
Perhaps this is best done in c-opts.c:sanitize_cpp_opts()
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-08 02:14 ---
I looked into this a little bit tonight.
The bug here is that the code for #error calls
cpp_output_line, which ends up calling
cpp_error_with_line when transforming the trigraph.
So, the trigraph warning is emitted
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-08 02:18 ---
With svn trunk, the .d file ends up in /tmp regardless of whether
preprocessing succeeds or fails.
This is also the case for the GCC 4.1.1 that shipped in FC 5.
So, I think this bug was probably fixed at some point
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-08 02:22 ---
I'm going to close this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-08 02:24 ---
What is the status of this?
The patch looks reasonable to me (though I can't approve it)
but seems to have been dropped.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-04 15:32 ---
Subject: Bug 28165
Author: tromey
Date: Thu Jan 4 15:32:26 2007
New Revision: 120441
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120441
Log:
libcpp
PR preprocessor/28165:
* internal.h
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-04 15:33 ---
I checked in a fix for this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- 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
--- 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 #3 from tromey at gcc dot gnu dot org 2006-12-30 23:11 ---
FWIW my initial attempt here, namely inserting %finput-charset*
into specs in various places, fails if multiple files are given
to gcc when -combine is not used (my patch handles the -combine
case). This is because
: 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 #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=gccview=revrev=120245
Log:
PR preprocessor/30001:
* charset.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|Removed
--- 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 org changed
--- 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 source file
--- 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 dot org
--- 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 expose a hidden
--- 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 are
in the expansion
--- 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/bugzilla
--- 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 gcc dot
--- 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
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-28 01:34 ---
This seems reasonable enough to me, offhand.
I suppose built-in and command line 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
--- 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 the --syntax-only output.
The problem
--- 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
--- 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 #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
--- 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 relying
--- 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
--
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 #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=gccview=revrev=119664
Log:
2006-12-08 Ben Konrath [EMAIL PROTECTED]
PR libgcj
--- 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=gccview=revrev=119665
Log:
2006-12-08 Ben Konrath [EMAIL PROTECTED]
PR libgcj
--- 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
--- 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 |Added
--- 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 2006-12-07 17
--- 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=gccview=revrev=119644
Log:
PR libgcj/30076:
* defineclass.cc (read_fields
--- 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
--
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
601 - 700 of 1564 matches
Mail list logo
