--- 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
--- 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
801 - 900 of 1894 matches
Mail list logo
