This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR c++/33207: ICE redeclaring namespace as struct


Simon Martin wrote:

>>> The problem is that the type for 'struct N', when processed by
>>> 'pushtag', is not completely setup: we leave the function earlier
>>> because we end up with error_mark_node after 'pushdecl_with_scope' since
>>> N is already the name of a namespace. In particular, the type's
>>> TYPE_STUB_DECL is not set, so it (and TYPE_MAIN_DECL) remains NULL_TREE.
>>
>> The guiding principle is that we don't want the internal representation
>> to represent an erroneous program; too many things can go wrong.  So, it
>> would be better not have a type at all in this case.  Is that feasible?

> Here's another try in that direction. I'm not familiar with this part of
> the code, so I'm not very confident with this patch... However, I've run
> out of ideas to fix this PR, so I submit this for feedback.

There's no question this kind of thing is complicated.  Thank you for
valiantly working on it.

> In the case where an implicit typedef must be created in 'pushtag', the
> associated binding is created before we know for sure that the type
> declaration is OK.

As you suggest below, I think that means we should do the check before
we create the implicit typedef.

> PS: I've also tried to create the implicit typedef after all the checks
> have been done on the type declaration. The regression tests were fine,
> but I'm not sure changing that the order is safe. In particular, the
> comment for set_identifier_type_value_with_scope states that ID should
> not be already defined, and I think that changing the order might break
> this "constraint"...

I don't fully understand the comment in the code to which you refer, but
I think the sequence you're suggesting is the right one: work out that
it's OK to have "struct S" first, and, then, and only then, create the
implicit "typedef struct S S;" typedef.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]