--- Comment #11 from tromey at gcc dot gnu dot org 2009-03-30 20:57 ---
Oops, updated wrong field.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tromey at gcc dot gnu dot org 2009-03-30 21:23 ---
It is not really a bug, but it is ugly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #11 from tromey at gcc dot gnu dot org 2009-03-30 21:50 ---
I am looking at it right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #4 from tromey at gcc dot gnu dot org 2009-03-30 23:22 ---
Try this.
I'll submit it if it regression tests ok.
Index: c-ppoutput.c
===
--- c-ppoutput.c(revision 145295)
+++ c-ppoutput.c(wo
--- Comment #6 from tromey at gcc dot gnu dot org 2009-04-08 16:37 ---
How would the FE indicate that the length field is immutable?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855
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=39705
epresented incorrectly in debug_pubnames
Product: gcc
Version: 4.5.0
Status: 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=39706
: 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=39707
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
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=39708
--- Comment #2 from tromey at gcc dot gnu dot org 2009-08-14 17:46 ---
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 2009-08-17 17:35 ---
Subject: Bug 41067
Author: tromey
Date: Mon Aug 17 17:34:53 2009
New Revision: 150854
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150854
Log:
PR preprocessor/41067:
* c
--- Comment #4 from tromey at gcc dot gnu dot org 2009-08-17 17:35 ---
I fixed the error message.
I probably will not address comment #2, but I will leave this
bug open for it instead.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tromey at gcc dot gnu dot org 2009-08-26 14:28 ---
Typedefs are found using lookup_name.
There is not really a separate mapping; instead the
trees are held directly in the identifier node.
These are reset as typedefs (or whatever) go out of scope,
though
--- Comment #3 from tromey at gcc dot gnu dot org 2009-09-01 16:58 ---
I think it isn't correct to use "gcc" directly.
You probably have to introduce a new variable.
But, I don't see why we need ecjx.cc at all.
I think it must be to work around some other probl
--- Comment #2 from tromey at gcc dot gnu dot org 2009-09-29 20:03 ---
This is obsoleted by the newer idea in PR 41130.
*** This bug has been marked as a duplicate of 41130 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2009-09-29 20:03 ---
*** Bug 39708 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
--- Comment #4 from tromey at gcc dot gnu dot org 2007-04-27 17:44 ---
Dan Berlin said if you log in first you should be able to attach things.
I downloaded rhino 1_6r5 from: http://www.mozilla.org/rhino/download.html
Then I tried the .class you sent me. I tried with gcj 4.1 (from the
--- Comment #12 from tromey at gcc dot gnu dot org 2007-05-02 20:33 ---
Subject: Bug 28709
Author: tromey
Date: Wed May 2 19:33:44 2007
New Revision: 124356
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124356
Log:
libcpp
PR preprocessor/28709:
*
--- Comment #13 from tromey at gcc dot gnu dot org 2007-05-02 20:34 ---
I checked in the follow-up patch to the trunk.
So this fully works on 4.3.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-14 20:57 ---
It is easy to forget to update this file, I'm sure that is what happened.
This only matters if you have CNI code that uses one of these classes.
So, it is definitely a problem, but generally not a very seriou
--- Comment #5 from tromey at gcc dot gnu dot org 2007-05-15 19:41 ---
The patch is incomplete, as libcpp/configure.in still checks for iconv.h.
Anyway the best thing to do here is submit a patch or patches to the
gcc patch list. Include a ChangeLog entry, etc.
--
tromey at gcc
--- Comment #3 from tromey at gcc dot gnu dot org 2007-05-22 19:11 ---
My recollection is that the special -I behavior is there because
the system headers have special non-warning properties.
This situation doesn't apply to -L.
> 2. Software is often compiled with configure, ma
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 16:33 ---
I think the proper fix here is to disable this warning in tools.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 17:18 ---
I think gjdoc only recently got support for generics and annotations.
So an older gjdoc is expected to fail. I haven't been keeping track
of gjdoc version numbers but I expect if you install a newer version
--- Comment #1 from tromey at gcc dot gnu dot org 2007-05-24 17:31 ---
Could you get a stack trace at the point of the ICE?
That might help.
If that doesn't help, though, all that remains is debugging jc1
to see what goes wrong.
If you have the time another thing to try is build
--- Comment #12 from tromey at gcc dot gnu dot org 2007-05-24 17:59 ---
Do you have a copyright assignment?
If so I will review the proposed patch.
I think the bigger problem is that the Qt peers are not really maintained.
ISTR that they still have some pretty serious bugs, though that
--- Comment #3 from tromey at gcc dot gnu dot org 2007-05-24 18:02 ---
Unless you need 4.1 and plan to work on this bug, I would like to close it.
What do you think?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31853
--- Comment #5 from tromey at gcc dot gnu dot org 2007-05-25 21:05 ---
Thanks for your response.
Closing as fixed in 4.2.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
--- Comment #6 from tromey at gcc dot gnu dot org 2007-06-02 21:52 ---
I see this bug when I compile the test case without -O.
I tried svn trunk and also 4.1.1 20070105 (Red Hat 4.1.1-51)
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:35 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org ch
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:36 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org ch
--- Comment #8 from tromey at gcc dot gnu dot org 2007-06-11 23:44 ---
I'm reopening this. Andrew P., please leave it open if you would.
We chose what goes into -Wall, and this is a bug in the
implementation of that choice.
--
tromey at gcc dot gnu dot org changed:
--- Comment #3 from tromey at gcc dot gnu dot org 2007-06-28 19:35 ---
Subject: Bug 30999
Author: tromey
Date: Thu Jun 28 19:35:25 2007
New Revision: 126090
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126090
Log:
2007-06-28 Jan Nijtmans <[EMAIL PROTECTED]&g
--- Comment #4 from tromey at gcc dot gnu dot org 2007-06-28 19:59 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
Product: gcc
Version: 4.3.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
--- Comment #1 from tromey at gcc dot gnu dot org 2007-07-05 17:31 ---
I tried this with svn trunk and got 'false'.
If there is a bug here it is in ecj, not gcj.
I'm not sure I agree with your interpretation here.
I don't see how specificity applies. Isn'
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-02
17:14 ---
I set the target milestone.
This patch looks like a 4.0 candidate to me.
Could you put it there?
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-02
17:15 ---
I don't think we'll import a new version of the GC into the 4.0.x series.
However, a patch to fix the ARM port would be perfectly fine.
If the patch works for you, please submit it to java-patches
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-02
21:46 ---
About comment #6 - it doesn't seem to me that this patch could have affected
the setting of BACKTRACESPEC. The most recent change there was on
01-Jun-05; see libjava/configure.host (via cvs annotate
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-05
16:15 ---
One reason I suspect a compiler bug and not a bug in 'instanceof'
is that the code works in the interpreter but not when BC-compiled.
Tom F... I think the arguments are reversed to the ca
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-05
21:24 ---
How embarrassing.
One question is whether we ought to change CNI to conform.
I suspect the answer is 'yes', for clarity's sake.
--
What|Removed
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-05
21:31 ---
I'm testing a patch
--
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-06
14:23 ---
Fix checked in to 4.0 branch and trunk.
--
What|Removed |Added
Status
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-06
16:04 ---
Fix checked in.
--
What|Removed |Added
Status|ASSIGNED
?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.35&r2=1.35.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natThread.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.30&r2=1.30.8.1
------- Additional Comments From tromey at gcc dot gnu dot org 2005-0
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-09
18:35 ---
Note also that Package.getVersion fails when the class file comes from a
jar. With the included example you can see this by making a manifest file
(in my example named "J/Man"):
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-15
22:05 ---
Fix checked in
--
What|Removed |Added
Status|NEW
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-21
14:29 ---
I had to make the methods in B and C public in order
to compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23620
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-25
21:09 ---
I'll handle this
--
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-25
21:35 ---
*** This bug has been marked as a duplicate of 23718 ***
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-25
21:35 ---
*** Bug 16832 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-26
19:58 ---
libffi bug that Gary found while doing builds on PPC64
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01605.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-27
17:34 ---
Should be fixed by recent classpath import.
--
What|Removed |Added
Status
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-27
19:48 ---
There seems little point in leaving this open now that 4.0 has shipped.
Any required patches should be mentioned in bug #24018
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-27
19:49 ---
We should fix bug #23367 on the branch, either by importing the
fix or by simply disabling the method cache.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24018
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-27
20:04 ---
Fixed on trunk; waiting for 4.0 thaw to fix there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23367
: 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
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24125
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-29
17:18 ---
I'm testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-30
00:37 ---
I checked in the fix to the 4.0 branch and the trunk.
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-30
16:15 ---
Fix checked in.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 24018 depends on bug 24148, which changed state.
Bug 24148 Summary: [gcc 4.0 only] Linux PPC64 libffi -vs- long double return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24148
What|Old Value |New Value
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-30
16:22 ---
Added PR 23367
--
What|Removed |Added
BugsThisDependsOn||23367
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-30
20:48 ---
This turns out to be somewhat tricky.
Automake's install rule will create a directory for a
conditionally-defined installable file even if the file
won't be installed by the current configuration
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-30
20:49 ---
Fix checked in.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-30
21:04 ---
Fix checked in.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 24018 depends on bug 23367, which changed state.
Bug 23367 Summary: _Jv_FindMethodInCache is not thread-safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23367
What|Old Value |New Value
-
--- Additional Comments From tromey at gcc dot gnu dot org 2005-10-01
19:47 ---
This was fixed a while ago and the fix has since been
imported into the libgcj build.
--
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-03 14:23 ---
Is there going to be a 3.4.5?
FWIW it would be somewhat more convenient if, say, whoever is
doing releases from 3.4 branch applied this patch. I don't have
it checked out, and going through a build is kind of a
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-03 14:26 ---
This is a duplicate.
I'm not sure what is going on with the patch in PR 23617...
*** This bug has been marked as a duplicate of 23617 ***
--
tromey at gcc dot gnu dot org changed:
What|Re
--- Comment #4 from tromey at gcc dot gnu dot org 2005-10-03 14:26 ---
*** Bug 24162 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-03 14:28 ---
Ben, you can send private email about this to the folks listed
as libgcj maintainers in the gcc MAINTAINERS file, namely Bryce
and me.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
--- Comment #5 from tromey at gcc dot gnu dot org 2005-10-03 19:08 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
Severity: normal
Priority: P2
Component: libgcj
AssignedTo: tromey at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24182
Product: gcc
Version: 4.1.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
http://gcc.gnu.org/bugzilla/show_bug.cgi
tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24184
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
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=24258
o: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24321
--- Comment #11 from tromey at gcc dot gnu dot org 2005-10-12 18:11 ---
Stewart, can you post attach your backtrace to the PR?
Something like "thread apply all bt" might be useful.
Thanks.
--
tromey at gcc dot gnu dot org changed:
What
--- Comment #6 from tromey at gcc dot gnu dot org 2005-10-23 06:47 ---
There's an Eclipse PR for this, fwiw:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=108720
If you look there you can see further motivation -- in particular,
the continuation messages that gcc sometimes print
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-24 18:47 ---
I'm still not clear on exactly why we see the same data here.
However, I suspect this can be fixed by adding 'seeded = true' to
SHA1PRNG.engineSetSeed().
--
tromey at gcc dot gnu dot org changed:
--
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 2005-10-24 19:31 ---
FWIW, I tried this with jamvm+classpath cvs, and got the expected result.
So it does appear to be gcj-specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24461
--- Comment #7 from tromey at gcc dot gnu dot org 2005-10-26 09:01 ---
Sorry for the delay on this.
The patch looks reasonable enough to me. It needs a small
amount of reformatting and a ChangeLog entry.
Also I think the call to signal() is not needed, a custom
handler is reset to the
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-31 17:48 ---
I'll handle this.
I agree, we need this alias.
That particular part of the code is generated by
the script libjava/scripts/encodings.pl.
Looking at the current IANA character-sets file, I see
there is only
--- Comment #4 from tromey at gcc dot gnu dot org 2005-10-31 17:51 ---
I'll handle this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2005-10-31 20:02 ---
See:
http://people.redhat.com/gbenson/SecurityException-throwers-1.4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21891
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-01 15:17 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
--- Comment #3 from tromey at gcc dot gnu dot org 2010-02-11 20:15 ---
This is a C bug, not a preprocessor bug, so I'm reassigning.
I suppose that it is really a documentation bug, but I didn't see a
category for that.
--
tromey at gcc dot gnu dot org changed:
--- Comment #17 from tromey at gcc dot gnu dot org 2010-02-11 20:18 ---
It would be really great if someone would update the sourceware.org
bugzilla at the same time, so we could run a single version on the machine.
--
tromey at gcc dot gnu dot org changed:
What
--- Comment #22 from tromey at gcc dot gnu dot org 2010-02-11 21:05 ---
Yes, I think we should not merge the databases.
All I meant was that we should have a single version of the code running.
And, when upgrading, upgrade both instances at the same time.
--
http://gcc.gnu.org
--- Comment #4 from tromey at gcc dot gnu dot org 2010-02-23 16:55 ---
It seems to me that, by analogy with constructors, we would want debuginfo
for all the destructors, so that "break X::~X" would put breakpoints in all
the clones.
Then we would need additional info
--- Comment #1 from tromey at gcc dot gnu dot org 2010-03-08 21:02 ---
zlib is not maintained as part of gcc -- it is just imported into
the tree for convenience.
As such we minimize the changes we make to zlib.
A change like this one should be reported to the real zlib maintainers
--- Comment #1 from tromey at gcc dot gnu dot org 2010-03-17 21:46 ---
I tried it and it works fine with svn head.
Make sure to rm a.h before trying with different flags.
Or, use -force.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #19 from tromey at gcc dot gnu dot org 2010-03-22 18:21 ---
Created an attachment (id=20163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20163&action=view)
undebugged patch to track macro expansion locations
I wanted to record my unfinished patch to trac
--- Comment #21 from tromey at gcc dot gnu dot org 2010-03-23 15:19 ---
> What is missing from this patch? Is it only the macro location tracked or the
> parameter expanded within the macro?
The biggest problem with the patch is that I didn't finish debugging it
--- Comment #7 from tromey at gcc dot gnu dot org 2010-03-23 16:11 ---
In the case where the default value is an expression,
would it be possible to just emit the expression as a string?
I believe that would be sufficient for gdb's purposes.
--
http://gcc.gnu.org/bug
Version: 4.5.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=43912
601 - 700 of 1570 matches
Mail list logo