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 mark at codesourcery dot com  2004-08-12 17:44 -------
Subject: Re:  [3.4/3.5 Regression] ICE on taking address of
 member in default parameter to member function

reichelt at igpm dot rwth-aachen dot de wrote:

>------- 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.
>  
>
OK, thanks.  And, would you please also reopen 16929?  I'll see what's 
up with your revised test case here.



-- 


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]