Re: RFC: handle case arising from GCC PR 47510

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Wed, 02 Feb 2011 23:03:55 +0100, Tom Tromey wrote:
> Tom> +public:
> Tom> +  C() {}
> Tom> +  ~C() {}
> 
> Jan> If the destructor is not present maybe_smash_one_typedef() will not
> Jan> work.  And GDB crashes now due to it, that should be
> Jan> sanity-protected anyway.
> 
> The class C is not the problem in this test case.  I think C just exists
> to make sure that the "anonymous" struct is not a POD.
> 
> maybe_smash_one_typedef won't be called for C, because C has a name.
> 
> I don't understand about GDB crashing now due to C.

C itself isn't a problem.  But as C no longer has a destructor even `t' no
longer has an implicit destructor.  Due to it maybe_smash_one_typedef gets
called for `t' but it does not do anything as it does not find the '~' field.

Then cp_lookup_nested_type crashes as TYPE_TAG_NAME (parent_type) == NULL
- which is correct for anonymous struct - but cp_lookup_nested_type does not
expect it.


> Jan> I do not fully grok this change, it goes half way.  Why two
> Jan> artificial methods are not non-unique?
> 
> My understanding is that this loop is trying to filter out artificial
> methods in a case like:
> 
>     class K {
>       K(int) { ... }
>     };
> 
> Here, I think, the user can type "ptype K::K" and get "K::K(int)" --
> which makes some kind of sense, ignoring the compiler-generated
> K::K(void).  At least, that is what I think it all means.  I am not sure
> this code is really correct, but this part of the patch is just avoiding
> a crash.
> 
> I don't think it is possible for this loop to see two artificial
> methods.

I thought about:
	class C { public: C() {} };
	class CC { C cf; } cc;
	class D : CC {} d;
	int main () {}
built with:
	GNU C++ 4.4.6 20110124 (prerelease)
producing:
	nm -C file
	00000000004005ac W CC::CC()
	0000000000400592 W CC::CC()
GDB HEAD:
	(gdb) p CC::CC
	Cannot reference virtual member function "CC"
GDB with your patch:
	(gdb) p CC::CC
	$1 = {void (CC * const)} 0x400592 <CC::CC()>
	(that is the 0x4005ac function is not shown to the user)

But this problem is not related to this patch as it happens even with
non-artificial constructors.  lookup_symbol_aux_symtabs just returns the first
matching symbol.  But one cannot specify demangled name for specific kind of
ctor/dtor so lookup_symbol_aux_symtabs must not error on non-unique match.
g++-4.5+ no longer generates multiple kinds of constructors during my tests so
it should not be much a real world concern anymore.

value_struct_elt_for_reference in this case sees only a single CC::CC entry as
the abstract structure itself has only one DIE for CC::CC.

So not an applicable issue for this patch.



Thanks,
Jan