--- Comment #31 from tromey at gcc dot gnu dot org 2010-09-07 15:50 ---
(In reply to comment #30)
$ cvs -z9 -d :ext:lpso...@sourceware.org:/cvs/sourceware co sourceware
cvs server: cannot find module `sourceware' - ignored
cvs [checkout aborted]: cannot expand modules
Use
--- Comment #4 from tromey at gcc dot gnu dot org 2010-08-31 18:33 ---
Created an attachment (id=21610)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21610action=view)
a simple test case
I'm attaching temargs.cc, a simple test case from the gdb test suite.
I compiled
--- Comment #3 from tromey at gcc dot gnu dot org 2010-08-31 20:12 ---
This was purely a gdb bug.
It only showed up with a newish gcc because older ones don't emit
DW_TAG_template_*.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
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=45110
Priority: P3
Component: tree-optimization
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=45083
--- Comment #1 from tromey at gcc dot gnu dot org 2010-07-26 15:53 ---
Created an attachment (id=21318)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21318action=view)
compressed .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
--- Comment #2 from tromey at gcc dot gnu dot org 2010-07-26 15:59 ---
Forgot some info:
opsy. gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/space/tromey/Trunk/install/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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 2010-07-26 16:12 ---
Created an attachment (id=21319)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21319action=view)
compressed .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45085
: 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=45088
: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45048
--- Comment #8 from tromey at gcc dot gnu dot org 2010-07-23 18:28 ---
Yeah, nobody is ever going to bother with this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2010-07-23 21:06 ---
I suppose the duplicate is due to the i inside of f.
But inside of f I see:
278: Abbrev Number: 7 (DW_TAG_lexical_block)
79 DW_AT_low_pc : 0x3
7d DW_AT_high_pc : 0x8
381: Abbrev
--- Comment #3 from tromey at gcc dot gnu dot org 2010-07-21 15:19 ---
The ordinary cases work fine with svn trunk gcc.
However, member pointers still don't have all the info emitted.
Consider this test case:
struct S { int f; };
templateint S::*MP struct T { };
TS::f v;
For v's type
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45024
--- Comment #3 from tromey at gcc dot gnu dot org 2010-07-19 18:44 ---
In the end, we decided not to use .debug_pubnames in gdb.
And, GCC no longer generates this section on most platforms.
So, I am closing this bug.
--
tromey at gcc dot gnu dot org changed:
What
--- Comment #15 from tromey at gcc dot gnu dot org 2010-06-15 21:51 ---
I think we've decided not to pursue this route.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2010-06-11 14:53 ---
I think the problem with this patch is that it leaves gdb no way
to determine which approach it should use. This is important because
there is a lot of existing code compiled with the incorrect approach.
Currently
--- Comment #5 from tromey at gcc dot gnu dot org 2010-06-11 15:07 ---
Jakub pointed out that gdb can just look for an isolated
DW_OP_constu to fall back to the old code.
I will write a gdb patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
--- Comment #6 from tromey at gcc dot gnu dot org 2010-06-11 20:02 ---
Ok, I committed the gdb change:
http://sourceware.org/ml/gdb-patches/2010-06/msg00287.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
--- Comment #1 from tromey at gcc dot gnu dot org 2010-05-28 16:58 ---
Here is what gcc trunk says:
opsy. gcc --syntax-only pr.c
pr.c: In function main:
pr.c:20:10: warning: initialization from incompatible pointer type [enabled by
default]
The particular case motivating this PR
: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
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
--- 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.
It causes regressions
--- 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/bugzilla
--- 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=20163action=view)
undebugged patch to track macro expansion locations
I wanted to record my unfinished patch to track macro
--- 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 #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 #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 information
--- 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:
What
--- 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 #2 from tromey at gcc dot gnu dot org 2010-02-05 18:04 ---
I tried this with some random svn trunk checkout, and it worked ok:
125: Abbrev Number: 2 (DW_TAG_namespace)
26 DW_AT_name: bar
2a DW_AT_decl_file : 1
2b DW_AT_decl_line
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=42959
--- Comment #3 from tromey at gcc dot gnu dot org 2009-12-14 16:26 ---
This seems to work better with svn trunk:
Breakpoint 2, func2 () at pr.c:5
5 return 0;
(gdb) fini
Run till exit from #0 func2 () at pr.c:5
0x080483c3 in main () at pr.c:13
13|| func2 ()
Value
--- Comment #5 from tromey at gcc dot gnu dot org 2009-12-08 17:58 ---
FWIW, I know that this patch will not affect the CVS gdb,
because that gdb never reads the .debug_aranges section.
I'll try this out using my branch today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288
--- Comment #3 from tromey at gcc dot gnu dot org 2009-12-07 15:57 ---
Yes, that's exactly what I would like. Thanks.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tromey at gcc dot gnu dot org 2009-12-07 21:32 ---
It would be best for gdb if gcc emitted an empty section if
there was nothing to index. See PR 42288 for an analogous case.
This is worth doing even though, in this situation, the resulting
CU won't really hold
: 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=42288
--- Comment #10 from tromey at gcc dot gnu dot org 2009-12-03 18:08 ---
Created an attachment (id=19218)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19218action=view)
updated gcc patch to put the CU's language in the new section
--
tromey at gcc dot gnu dot org changed
--- Comment #11 from tromey at gcc dot gnu dot org 2009-12-03 18:09 ---
Created an attachment (id=19219)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19219action=view)
updated binutils patch to account for language in new index
--
tromey at gcc dot gnu dot org changed
--- Comment #12 from tromey at gcc dot gnu dot org 2009-12-03 18:16 ---
I compiled a C++ program with a gcc that includes this patch.
I see some erroneous entries in the resulting index. E.g.:
0xb8 DW_TAG_structure_type._6
0x3f1 DW_TAG_structure_type
--- Comment #9 from tromey at gcc dot gnu dot org 2009-12-02 19:40 ---
Created an attachment (id=19214)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19214action=view)
patch for readelf
This is an updated readelf patch.
Now readelf -wI works properly.
--
tromey at gcc dot gnu
--- Comment #7 from tromey at gcc dot gnu dot org 2009-11-19 16:30 ---
Created an attachment (id=19055)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19055action=view)
modified patch
I've slightly updated the patch to handle non-public entities
as well.
--
http://gcc.gnu.org
--- Comment #8 from tromey at gcc dot gnu dot org 2009-11-19 16:45 ---
Created an attachment (id=19056)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19056action=view)
patch for readelf
This patch modifies the binutils readelf utility to
dump the new section.
--
http
--- 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 #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 problem.
Maybe instead we could
--- 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-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=gccview=revrev=150854
Log:
PR preprocessor/41067:
* charset.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
: 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=41048
: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40990
--- Comment #1 from tromey at gcc dot gnu dot org 2009-06-30 20:05 ---
Fixed on trunk:
2009-06-11 Richard Henderson r...@redhat.com
* common.opt (gdwarf-): Accept a version number.
* doc/invoke.texi (gdwarf-): Update docs.
* opth-gen.awk: Special case -gdwarf
--- Comment #3 from tromey at gcc dot gnu dot org 2009-06-10 22:58 ---
Subject: Bug 40289
Author: tromey
Date: Wed Jun 10 22:58:22 2009
New Revision: 148357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148357
Log:
PR libstdc++/40289:
* python/Makefile.in
--- Comment #4 from tromey at gcc dot gnu dot org 2009-06-10 23:06 ---
I changed this to install the code in a versioned directory.
I think this fixes the problem; reopen this PR if not.
--
tromey at gcc dot gnu dot org changed:
What|Removed
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380
--
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 2009-05-29 18:11 ---
I'm working on a fix.
Distro folks will probably want to rewrite the hook file and stick
it somewhere else. The auto-loading search path is documented in the
gdb manual.
--
http://gcc.gnu.org/bugzilla
: 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
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
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 #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
--- 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=gccview=revrev=145300
Log:
PR preprocessor/39512:
* line-map.c
--- 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=gccview=revrev=145316
Log:
2009-03-30 Sergiy Vyshnevetskiy s...@vostok.net
PR
--- 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 #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(working
--- 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|Removed
--- 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 |Added
--- 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.
--
http
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 #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 with the spec
--- 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
--- 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 in
the size
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=38757
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:33 ---
Changing component to pch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:39 ---
Please report the bug in comment #2 separately.
Otherwise it is unlikely to be seen by the appropriate person.
Andrew is correct; this would probably be fixed if we had gcc
tell libcpp to use its diagnostic code
--- Comment #3 from tromey at gcc dot gnu dot org 2009-01-02 16:44 ---
You can try -C to keep the comments.
In the original report you said you can't get a backtrace.
That makes it a lot harder :(
Could you try shrinking the test case somehow?
Or perhaps you could change the abort
--- Comment #6 from tromey at gcc dot gnu dot org 2009-01-02 17:04 ---
read_original_filename lexes a token, which hits EOF, which
causes the buffer to be popped.
This is sort of an odd scenario.
Perhaps working around it in preprocess_file is best.
--
tromey at gcc dot gnu dot org
--- Comment #1 from tromey at gcc dot gnu dot org 2008-11-17 17:29 ---
According to my reading of the standard, this code is in fact incorrect.
This is basically the same as #36320.
I'm beginning to wonder, though, whether this change was overly eager on my
part
and should be made
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|Removed
--- 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
: 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
--- 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 the declared type
--- 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 string
using namespace std;
std::string x1;
string x2;
If we record the fully qualified name, we can't distinguish
--- 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 |Added
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 string
std::string zardoz1;
using std::string;
string zardoz2;
In this case, IMO, 'whatis' should print 'std::string' for zardoz1,
but just 'string' for zardoz2.
This is simply
--- 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 wants to clean
--- 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 string.h
char (*fnptr)() = rindex;
I tend to agree with Andrew -- poisoning is too crude a tool for this use.
Is there a reason you do
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37259
--- 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
1 - 100 of 1564 matches
Mail list logo
