This is the mail archive of the gcc-bugs@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]

[Bug c++/16929] [3.4/3.5 Regression] ICE on taking address of member in default parameter to member function


------- Additional Comments From reichelt at igpm dot rwth-aachen dot de  2004-08-12 15:10 -------
Subject: Re:  [3.4/3.5 Regression] ICE on taking address of
 member in default parameter to member function

On 12 Aug, mark at codesourcery dot com wrote:

>>Mark, I don't think your fix for PR 16929 is the right approach.
>>We still accept code like the following:
>>
>>=====================================
>>template<typename> struct A {};
>>
>>template<typename T> struct B
>>{
>>    A<T> a;
>>
>>    void foo(A<T> = a);
>>};
>>=====================================
>>
>>which is invalid IMHO (we still reject it on the 3.3 branch as does
>>icc with -strict_ansi).
>>
> My fix is certainly going to do no harm, and it probably helps with 
> other situations that involve explicit use of the "this" keyword in the 
> default arguments.  (Like "x = this").
> 
> The standard doesn't really say whether you have to diagnose this at 
> declaration time, or instantiation time. You're right that it's 
> generally nice to catch things early.  You can file a PR, but I think 
> it's a QoI issue, or a regression in terms of diagnostic quality.

I actually wanted to point out a different problem:
The problem is, that the default parameter "a" is not even diagnosed at
instantiation time. Note, it's "a" instead of "&a"!

Sorry for packing two unrelated issues in my new testcase.
So here's a new one that focusses on one issue.

===========================================
template<typename> struct A {};

template<typename T> struct B
{
    A<T> a;

    void foo(A<T> = a);
};

template struct B<int>;
===========================================

As suggested, I'll open a new PR for the QoI issue you mentioned.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16929


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