--- 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 mo
--- 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 |
--- 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=21610&action=view)
a simple test case
I'm attaching "temargs.cc", a simple test case from the gdb test suite
ion: 4.6.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=45110
y: pointer type information lost in debuginfo
Product: gcc
Version: 4.6.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=45088
--- 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=21319&action=view)
compressed .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45085
rning
Product: gcc
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/
--- 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 with
--- 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=21318&action=view)
compressed .i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45083
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=45083
--- 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:
<2><78>: Abbrev Number: 7 (DW_TAG_lexical_block)
<79> DW_AT_low_pc : 0x3
&l
--- 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
Product: gcc
Version: 4.6.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=45048
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=45024
--- 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; };
template struct T { };
T<&S::f> v;
For v
--- 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 |
--- 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 #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 #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 #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 was
gnedTo: 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 #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
--- 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 #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 #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 info
--- 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 #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 #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 #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:
<1><25>: Abbrev Number: 2 (DW_TAG_namespace)
<26> DW_AT_name: bar
<2a> DW_AT_decl_fi
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 #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
--- 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 |
: 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 #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 #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=19219&action=view)
updated binutils patch to account for language in new index
--
tromey at gcc dot gnu dot org
--- 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=19218&action=view)
updated gcc patch to put the CU's language in the new section
--
tromey at gcc dot gnu dot
--- 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=19214&action=view)
patch for readelf
This is an updated readelf patch.
Now "readelf -wI" works properly.
--
--- 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=19056&action=view)
patch for readelf
This patch modifies the binutils readelf utility to
dump the new section.
--
--- 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=19055&action=view)
modified patch
I've slightly updated the patch to handle non-public entities
as well.
--- 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 #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 #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 #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 #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 #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 #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
from g++
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=41048
--- Comment #7 from tromey at gcc dot gnu dot org 2009-08-09 00:09 ---
The earlier comments should probably first be investigated by looking
in config.log. (Except the original comment which sounds like a missing
feature in depcomp -- that should go upstream to Automake.)
Comment #5
tedBy: 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
* common.opt (gdwarf-): Accept a version number.
* doc/invoke.texi (gdwarf-): Update docs.
* opth-gen.awk: Special case -gdwarf+ to
--- 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
--- 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=gcc&view=rev&rev=148357
Log:
PR libstdc++/40289:
* python/Mak
nu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380
--- 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.g
--
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
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
: 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
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
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
--- 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 #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 #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 #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 20:57 ---
Oops, updated wrong field.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- 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 #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 #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 #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:15 ---
Not a bug.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- 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 #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: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 #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.
--
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 #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 #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 #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
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 #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 #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
--- 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:33 ---
Changing component to pch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- 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
--- 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-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
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
: 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 t
--- 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 #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 #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
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 #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 |
--- 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
1 - 100 of 1570 matches
Mail list logo
