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

Simon Martin simartin@users.sourceforge.net
Sat Sep 22 02:11:00 GMT 2007


Hi Mark.

Thanks for reviewing this.

>> 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.

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. In particular the check that detects that 'struct N;'
is invalid in this testcase (because N is already a namespace name) is
done afterwards.

As a consequence, we end up with an implicit typedef towards a type that
has not been pushed because it's invalid, which triggers an ICE.

The attached patch fixes this by removing the binding that has been
created via the implicit typedef when the associated type declaration
turns out to be invalid. 'pop_binding' looked like a good candidate for
this (it does exactly what is needed), but it cannot be used as is
because it relies on the value IDENTIFIER_BINDING for 'name', which is
not set here. I therefore artificially set it with the binding that has
been created (i.e. the one I'm trying to remove) before calling
'pop_binding'. I hope it's OK to do so...

I have successfully regtested it on i386-apple-darwin8.10.1. Is it better?

Thanks in advance,
Simon

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"...


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_33207_4
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070922/01ddba8a/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr33207_4.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070922/01ddba8a/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CL_33207_testsuite
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070922/01ddba8a/attachment-0002.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash38.C
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070922/01ddba8a/attachment-0003.ksh>


More information about the Gcc-patches mailing list