This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: PR c++/39060: [4.4 regression] ICE with lots of invalid member functions
On Sat, Mar 7, 2009 at 1:46 PM, Jason Merrill <jason@redhat.com> wrote:
> H.J. Lu wrote:
>>
>> On Sat, Mar 7, 2009 at 1:23 PM, Jason Merrill <jason@redhat.com> wrote:
>>>
>>> H.J. Lu wrote:
>>>>
>>>> This patch returns NULL if default_argument is error_mark_node.
>>>
>>> So if parsing the default argument fails, we pretend the parameter itself
>>> didn't exist? ?Why does that work better than just setting
>>> default_argument
>>> to NULL_TREE?
>
>> I still got
>
>> /tmp/x.ii:19: internal compiler error: canonical types differ for
>> identical types void (A::)(void*) and void (A::)(void*)
>
> Yes, I expected that it wouldn't work better, I was curious why it makes a
> difference. ?It seems that the problem is coming in when we build the method
> type.
I think we are trying too hard to recover from error. Do we really need to
make C++ front end so complex just to recover from fatal errors? Icc
generates:
x.ii(7): error: invalid redeclaration of member function "A::A(void
*)" (declared at line 6)
A(void* i=);
^
x.ii(8): error: invalid redeclaration of member function "A::A(void
*)" (declared at line 6)
A(void* i=);
^
x.ii(10): error: default argument is not allowed
void operator+ (void* i=);
^
x.ii(10): error: expected an expression
void operator+ (void* i=);
^
x.ii(12): error: expected a type specifier
virtual void foo1(=);
^
x.ii(13): error: expected a type specifier
void foo2(=);
^
x.ii(14): error: expected a type specifier
void foo3(=);
^
x.ii(15): error: expected a type specifier
void foo4(=);
^
x.ii(16): error: expected a type specifier
void foo5(=);
^
x.ii(6): error: expected an expression
A(void* i=);
^
x.ii(19): error: expected an expression
A::A (void* i=) {}
^
x.ii(19): error: redefinition of default argument
A::A (void* i=) {}
^
compilation aborted for x.ii (code 2)
--
H.J.