--- Additional Comments From tromey at gcc dot gnu dot org 2005-02-19
00:19 ---
I investigated this some more.
The code generator for "return" looks at the finally
stack to decide whether to call any finally handlers.
But, the code generator for "try" has a s
--- Additional Comments From tromey at gcc dot gnu dot org 2005-02-19
01:52 ---
I've checked in the fix for this.
--
What|Removed |Added
Status|ASS
tatus: UNCONFIRMED
Severity: enhancement
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-prs at gcc dot gnu
--- Additional Comments From tromey at gcc dot gnu dot org 2005-02-20
22:32 ---
I've checked in this patch
--
What|Removed |Added
Statu
.class twice
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 dot org
CC: gcc-bugs
c dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
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=20507
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-17
02:17 ---
Are there other threads running?
If so, could you send stack traces from these as well?
If not, then something more serious has gone wrong on your system, as it is
hanging on a mutex in the C library
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-22
20:37 ---
I'm testing a patch for this.
--
What|Removed |Added
AssignedTo|unassigned a
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23
20:51 ---
FWIW, we do support "-ms" and "-mx", but not "-Xms" and "-Xmx".
Those are just ignored.
However, we ought to recognize those. I'm leaving the PR open for now,
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23
21:37 ---
Fix checked in.
--
What|Removed |Added
Status|NEW
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23
21:37 ---
Fix checked in.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23
21:38 ---
Fix checked in.
--
What|Removed |Added
Status|NEW
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23
21:38 ---
Fix checked in.
--
What|Removed |Added
Status|NEW
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-23
21:39 ---
Fix checked in.
--
What|Removed |Added
Status|NEW
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-24
16:57 ---
According to Sven, the recent Calendar/SimpleDateFormat fix
fixed this as well.
--
What|Removed |Added
--
Bug 16990 depends on bug 8321, which changed state.
Bug 8321 Summary: SimpleTimeZone doesn't work properly for daylight saving time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8321
What|Old Value |New Value
--
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-24
17:00 ---
*** Bug 19682 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-03-24
17:00 ---
Duplicate PR.
*** This bug has been marked as a duplicate of 17003 ***
--
What|Removed |Added
--
Bug 16990 depends on bug 19682, which changed state.
Bug 19682 Summary: TimeZone data needs to be regenerated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19682
What|Old Value |New Value
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-05
20:15 ---
Could you attach the ecj-generated bytecode for this file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20768
--- Additional Comments From tromey at gcc dot gnu dot org 2005-04-14
18:05 ---
For 4.0, my recent system class loader patch works around this problem.
The attached patch should go in the trunk asap.
I looked at all other users of _Jv_FindClassFromSignature,
and this was the only
--- Comment #7 from tromey at gcc dot gnu dot org 2008-08-04 18:31 ---
I didn't fix anything.
AFAIK the classpath configury still does not check versions.
I'm moving this to the classpath product.
It should be fixed there.
--
tromey at gcc dot gnu dot org changed:
--- Comment #8 from tromey at gcc dot gnu dot org 2008-08-04 18:32 ---
Hmm, I could not get bugzilla to change the product.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32028
--- Comment #4 from tromey at gcc dot gnu dot org 2008-08-04 18:52 ---
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 2008-08-05 01:29 ---
Subject: Bug 31890
Author: tromey
Date: Tue Aug 5 01:28:26 2008
New Revision: 138664
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138664
Log:
PR libgcj/31890:
* gcj/javaprims.h: Re
--- Comment #9 from tromey at gcc dot gnu dot org 2008-08-07 20:28 ---
See this note for some details on the semantics of this warning,
with respect to keywords:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00808.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
--- Comment #2 from tromey at gcc dot gnu dot org 2008-08-07 21:33 ---
This works in 4.3, probably due to the switch to mapped locations.
I didn't try anything earlier.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from tromey at gcc dot gnu dot org 2008-08-10 22:17 ---
> I am not sure how that will work. How do you specify a different value of
> system_header for a single location? My understanding is that sysp is for a
> whole line_map, so you cannot just change its va
--- Comment #14 from tromey at gcc dot gnu dot org 2008-08-11 02:18 ---
Just FYI -- I was thinking of PR 36478.
I'll respond to the rest later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
--- Comment #17 from tromey at gcc dot gnu dot org 2008-08-19 19:28 ---
Maybe libcpp could have a mode where it also recognizes the __extension__
token?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
u dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37259
--- Comment #3 from tromey at gcc dot gnu dot org 2008-09-02 19:22 ---
One problem with this approach is that this code would not error:
#include
char (*fnptr)() = rindex;
I tend to agree with Andrew -- poisoning is too crude a tool for this use.
Is there a reason you do not use
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 17:37 ---
FWIW -- on trunk, debug_str is controlled by -fmerge-debug-strings,
which is enabled by default (on supporting platforms).
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from tromey at gcc dot gnu dot org 2008-09-19 17:42 ---
I'm closing this.
It is fixed on mainline and is not apparently a regression.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
ld emit different debug info for variable's type
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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=37590
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 18:59 ---
Consider this code:
#include
std::string zardoz1;
using std::string;
string zardoz2;
In this case, IMO, 'whatis' should print 'std::string' for zardoz1,
but just 'string' fo
--- Comment #4 from tromey at gcc dot gnu dot org 2008-09-19 21:38 ---
FWIW -- I think this patch turned out to have some GC-related bug.
And, I don't think I need this for the incremental branch either, any more.
So, I'm just dropping it and closing this.
If someone else want
--- Comment #5 from tromey at gcc dot gnu dot org 2008-09-22 15:19 ---
No, I think we have to record what the user actually wrote.
For instance, consider:
#include
using namespace std;
std::string x1;
string x2;
If we record the fully qualified name, we can't distinguish thes
--- Comment #7 from tromey at gcc dot gnu dot org 2008-09-23 20:48 ---
Jan> Tom, could you elaborate why x1 and x2 should be printed differently?
Jan> I do not say they should not but I do not see a clear reason for either
way.
My view is that "whatis" should print t
: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
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=37959
Component: debug
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=38058
--- Comment #2 from tromey at gcc dot gnu dot org 2008-11-08 00:57 ---
I agree. I didn't see that one since I searched for the full tag name.
*** This bug has been marked as a duplicate of 30161 ***
--
tromey at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from tromey at gcc dot gnu dot org 2008-11-08 00:57 ---
*** Bug 38058 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30161
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-17 20:19 ---
Confirmed.
>From the ChangeLog it looks like the intent was to only reject
aggregate types.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-17 20:23 ---
Testing a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #9 from tromey at gcc dot gnu dot org 2008-01-17 22:25 ---
>From comment #6:
> What are the problems with the old implementation? Would it make
> sense to resurrect it as natProcessNoThread.c or something?
See PR 11801 for the problems with the old imple
--- Comment #8 from tromey at gcc dot gnu dot org 2008-01-18 21:52 ---
Changing component; the patch here doesn't touch the preprocessor at all.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-19 06:55 ---
These two macros are mentioned in footnotes in the C standard.
I think we should accept them.
Take a look at DR #593 here, though:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2130.html
I don't h
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-19 18:06 ---
I'm closing because the original reporter could not reproduce.
If you think this is in error, post a note here and I will reopen this.
--
tromey at gcc dot gnu dot org changed:
What|Re
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-21 20:00 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #4 from tromey at gcc dot gnu dot org 2008-01-21 20:09 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-21 20:09 ---
Subject: Bug 34369
Author: tromey
Date: Mon Jan 21 20:08:38 2008
New Revision: 131701
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131701
Log:
2008-01-21 Luciano Chavez <[EMAIL PROTECTED]&g
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-22 17:55 ---
Subject: Bug 34829
Author: tromey
Date: Tue Jan 22 17:54:59 2008
New Revision: 131732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131732
Log:
gcc/testsuite
PR c++/34829:
* g+
--- Comment #6 from tromey at gcc dot gnu dot org 2008-01-22 17:57 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from tromey at gcc dot gnu dot org 2008-01-22 21:43 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from tromey at gcc dot gnu dot org 2008-01-22 21:44 ---
Subject: Bug 34859
Author: tromey
Date: Tue Jan 22 21:43:49 2008
New Revision: 131743
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131743
Log:
libcpp
PR c++/34859:
*
--- Comment #3 from tromey at gcc dot gnu dot org 2008-01-22 21:51 ---
It is easy to reject bools, but I wonder if that is enough.
It is interesting that handle_vector_size_attribute doesn't
call vector_mode_valid_p, but the corresponding mode attribute does.
Anyway, I can re
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-23 01:05 ---
AFAICT vector_mode_valid_p knows about this fallback option.
Is that incorrect? See the last line...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34911
--- Comment #9 from tromey at gcc dot gnu dot org 2008-01-23 16:43 ---
Reopened while I look at the new problem
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2008-01-23 17:59 ---
Fix checked in a while ago.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from tromey at gcc dot gnu dot org 2008-01-25 20:48 ---
The second patch is fine by me, you might as well commit it now.
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
--- Comment #13 from tromey at gcc dot gnu dot org 2008-01-30 01:19 ---
> other
> than that, I'm not aware of any commonly used K&R bits and pieces in a modern
> system.
FWIW -- Emacs is mostly K&R.
--
tromey at gcc dot gnu dot org changed:
--- Comment #2 from tromey at gcc dot gnu dot org 2008-02-05 17:02 ---
I think you need an additional -I pointing to the directory
containing the JDK's jni_md.h.
Can you confirm this and get back to me?
--
tromey at gcc dot gnu dot org changed:
What|Re
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35089
--- Comment #1 from tromey at gcc dot gnu dot org 2008-02-05 17:09 ---
Probably a dup of PR 9463.
What locale are you using? How is the umlaut encoded in the directory name?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tromey at gcc dot gnu dot org 2008-02-20 18:38 ---
I'll handle it.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #10 from tromey at gcc dot gnu dot org 2008-02-20 19:09 ---
Subject: Bug 24170
Author: tromey
Date: Wed Feb 20 19:09:09 2008
New Revision: 132491
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132491
Log:
PR libgcj/24170:
* java/io/natFile
--- Comment #11 from tromey at gcc dot gnu dot org 2008-02-20 19:10 ---
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 2008-02-20 21:10 ---
Based on the command line it looks like your system gjar is crashing.
Is that the case?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2008-02-25 21:10 ---
Sorry for the delay on this.
I never remember our rules about when to emit pedantic warnings
and the like. I think libcpp should follow the overall gcc approach
here, whatever that is.
I agree that warning about
--- Comment #16 from tromey at gcc dot gnu dot org 2008-02-26 20:48 ---
*** Bug 35312 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2008-02-26 20:48 ---
I agree, closing as dup.
I have a patch for that bug. I forget what happened to it, but I'll
look into it soon.
*** This bug has been marked as a duplicate of 22168 ***
--
tromey at gcc dot gnu dot org ch
--- Comment #2 from tromey at gcc dot gnu dot org 2008-02-29 21:56 ---
Confirmed.
We probably need to make and upload a new canonical ecj jar.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2008-03-06 18:09 ---
Subject: Bug 35458
Author: tromey
Date: Thu Mar 6 18:08:40 2008
New Revision: 132982
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132982
Log:
libcpp
2008-03-06 Markus Milleder <[EMAI
--- Comment #5 from tromey at gcc dot gnu dot org 2008-03-06 18:15 ---
I agree with comment #3.
This is an improvement.
Users concerned with real portability should be avoiding "#" anyhow.
--
tromey at gcc dot gnu dot org changed:
What
--- Comment #2 from tromey at gcc dot gnu dot org 2008-03-13 15:48 ---
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 2008-03-13 15:53 ---
I tried this but was unable to see the ICE.
I used trunk, both gcc and g++.
What options did you use? Anything special?
If you still see an ICE, could you perhaps append a stack trace from cc1?
That might help
--- Comment #3 from tromey at gcc dot gnu dot org 2008-03-13 21:10 ---
Subject: Bug 35322
Author: tromey
Date: Thu Mar 13 21:10:07 2008
New Revision: 133195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133195
Log:
gcc/testsuite
PR libcpp/35322:
* gc
--- Comment #4 from tromey at gcc dot gnu dot org 2008-03-13 21:11 ---
Fixed on trunk.
I'm never sure if I should close these PRs or not.
It is a regression on the older branches, but minor enough that I
doubt anybody will want to back-port the fix.
--
tromey at gcc dot gnu do
--- Comment #6 from tromey at gcc dot gnu dot org 2008-03-14 15:45 ---
Subject: Bug 35322
Author: tromey
Date: Fri Mar 14 15:44:56 2008
New Revision: 133220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133220
Log:
2008-03-14 Uros Bizjak <[EMAIL PROTECTED]&g
--- Comment #9 from tromey at gcc dot gnu dot org 2008-03-14 21:25 ---
I'm testing this patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from tromey at gcc dot gnu dot org 2008-03-18 17:03 ---
I agree we should probably change ecj1's interpretation of -Wall.
But, ecj1 can't be part of gcc. That was already decided.
I believe the installation instructions have information on what
to download s
--- Comment #1 from tromey at gcc dot gnu dot org 2008-03-25 19:25 ---
Confirmed.
This is related to the column number stuff.
The current status here is that errors issued by the parser itself
all have been audited for proper location use; however the rest of the
C front end has not
--- Comment #6 from tromey at gcc dot gnu dot org 2008-04-04 14:33 ---
Confirmed.
I think the best behavior is a bit unclear.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2008-04-04 16:28 ---
I tried this test case and as far as I can tell it works as expected.
Can you say what you think is wrong?
I thought perhaps you were misreading the error output. The errors
from the initial report are:
z1.cc:2:1
--- Comment #6 from tromey at gcc dot gnu dot org 2008-04-04 16:39 ---
It is no trouble. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33143
--- Comment #4 from tromey at gcc dot gnu dot org 2008-04-05 13:30 ---
With trunk I still can't reproduce this.
I ran valgrind on cc1 and cc1plus, and see no reports.
Here's the command line I'm using:
valgrind
/home/tromey/gnu/Trunk/install/libexec/gcc/i686-pc-linux-gn
--- Comment #2 from tromey at gcc dot gnu dot org 2009-02-13 17:54 ---
This line looks fishy:
+ boffset = cbuf->position();
boffset is a byte offset from the start of 'data' to the first character.
So, you probably need to multiply by sizeof(jchar) and also add i
--- Comment #6 from tromey at gcc dot gnu dot org 2009-02-22 17:04 ---
I'm not sure that suggestion will work.
My recollection is that the order of checks is specified,
and that allocating memory before the abstract-ness check
would be incorrect.
I didn't confirm this wit
--- Comment #1 from tromey at gcc dot gnu dot org 2009-02-22 17:12 ---
This is not really a bug.
In this scenario, cc1 is executed multiple times. Each invocation
overwrites the -MF file.
A fix is not to pass multiple .c files to a given invocation of gcc.
Perhaps we should note
Component: debug
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=39436
--- Comment #10 from tromey at gcc dot gnu dot org 2009-03-28 01:15 ---
I think this patch looks ok, assuming it works.
I'd like to reiterate that all this vector stuff would
probably be much cleaner if it were implemented as
context-sensitive keywords in the parser.
--
--- Comment #1 from tromey at gcc dot gnu dot org 2009-03-30 01:15 ---
This is not really a bug. I don't think -MM is intended to work
with -combine.
This restriction should be documented, though.
--
tromey at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from tromey at gcc dot gnu dot org 2009-03-30 01:38 ---
convert_to_integer sets TREE_NO_WARNING on the shift,
causing cc1 to later bypass the warning.
#0 convert_to_integer (type=0xb7cf62d8, expr=0xb7cee630)
at ../../trunk/gcc/convert.c:542
#1 0x080a7069 in convert
--- Comment #1 from tromey at gcc dot gnu dot org 2009-03-30 01:43 ---
Thanks. I'll fix this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from tromey at gcc dot gnu dot org 2009-03-30 15:15 ---
Not a bug.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from tromey at gcc dot gnu dot org 2009-03-30 15:26 ---
Subject: Bug 39512
Author: tromey
Date: Mon Mar 30 15:25:42 2009
New Revision: 145300
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145300
Log:
PR preprocessor/39512:
* li
--- Comment #3 from tromey at gcc dot gnu dot org 2009-03-30 15:26 ---
I checked in the fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tromey at gcc dot gnu dot org 2009-03-30 20:54 ---
Subject: Bug 31932
Author: tromey
Date: Mon Mar 30 20:54:18 2009
New Revision: 145316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145316
Log:
2009-03-30 Sergiy Vyshnevetskiy
PR prep
--- Comment #10 from tromey at gcc dot gnu dot org 2009-03-30 20:57 ---
I checked in the fix on the trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
501 - 600 of 1570 matches
Mail list logo
