[Bug c++/16929] New: ICE on taking address of member in default parameter to member function

[Bug c++/16929] New: ICE on taking address of member in default parameter to member function

[niemayer at isg dot de]

Compiling the following tiny C++ code sample causes gcc-3.4.1 to crash:

-----------------------------------------------------
template <class T>
class A {
    int x;
};

template <class T>
class B {
protected:
    
    A<T> a;
    
    void f(const A<T> * a1 = &a);
    
    void g(void);
};

template <class T>
void B<T>::g(void) {
    f();
}

template class B<long>;
----------------------------------------------

Result when compiled:

bug.cxx: In instantiation of `void B<T>::g() [with T = long int]':
bug.cxx:23:   instantiated from here
bug.cxx:20: internal compiler error: Segmentation fault
Please submit a full bug report, 

I guess that the default parameter usage may be invalid code, but of course the
compiler shouldn't crash...

-- 
           Summary: ICE on taking address of member in default parameter to
                    member function
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: niemayer at isg dot de
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

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

[niemayer at isg dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens dot maurer at gmx dot
                   |                            |net


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-09 09:55 -------
Confirmed. I do not know if this is valid code or not but this is a regression never the less.

The mainline accepts the code.
The 3.4 branch ICEs on the code.
The 3.3 branch rejects the code.

When the ICE came about:
: Search converges between 2004-03-15-3.4 (#3) and 2004-04-01-3.4 (#4).
: Search converges between 2004-03-01-trunk (#446) and 2004-04-01-trunk (#447).

Accepting the code (most likely when the new parser came in):
: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160).

Fixed on the mainline if this is valid code:
: Search converges between 2004-04-20-trunk (#449) and 2004-05-01-trunk (#450).


Just a note ICC 6.0 rejects the code so does Comeau C++ online test.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-08-09 09:55:58
               date|                            |
            Summary|ICE on taking address of    |[3.4/3.5? Regression] ICE on
                   |member in default parameter |taking address of member in
                   |to member function          |default parameter to member
                   |                            |function
   Target Milestone|---                         |3.4.2


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

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

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-09 12:01 -------
The code is invalid: taking the address of a non-static member references 
the 'this' pointer, which is specificly not allowed by the standard for 
default arguments. 
 
The fact that 3.5 accepts the code is therefore an accepts-invalid, and as 
much a regression as the ICE in 3.4. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, ice-on-
                   |                            |invalid-code
      Known to fail|                            |3.4.1 3.5.0
      Known to work|                            |2.95 3.2 3.3
            Summary|[3.4/3.5? Regression] ICE on|[3.4/3.5 Regression] ICE on
                   |taking address of member in |taking address of member in
                   |default parameter to member |default parameter to member
                   |function                    |function


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

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-08-11 22:13 -------
Subject: Bug 16929

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2004-08-11 22:13:32

Modified files:
	gcc/cp         : ChangeLog parser.c pt.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/parse: error16.C 
	gcc/testsuite/g++.dg/template: error14.C error15.C 

Log message:
	PR c++/16964
	* parser.c (cp_parser_class_specifier): Robustify.
	
	PR c++/16904
	* pt.c (tsubst_copy_and_build): Complain about invalid
	qualification.
	
	PR c++/16929
	* pt.c (tsubst_default_argument): Clear out current_class_ptr and
	current_class_ref while tsubsting.
	
	PR c++/16964
	* g++.dg/parse/error16.C: New test.
	
	PR c++/16904
	* g++.dg/template/error14.C: New test.
	
	PR c++/16929
	* g++.dg/template/error15.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4269&r2=1.4270
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.233&r2=1.234
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.901&r2=1.902
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4118&r2=1.4119
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/error16.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error14.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error15.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

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

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-08-11 22:14 -------
Subject: Bug 16929

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	mmitchel@gcc.gnu.org	2004-08-11 22:14:44

Modified files:
	gcc/cp         : ChangeLog parser.c pt.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/parse: error16.C 
	gcc/testsuite/g++.dg/template: error14.C error15.C 

Log message:
	PR c++/16964
	* parser.c (cp_parser_class_specifier): Robustify.
	
	PR c++/16904
	* pt.c (tsubst_copy_and_build): Complain about invalid
	qualification.
	
	PR c++/16929
	* pt.c (tsubst_default_argument): Clear out current_class_ptr and
	current_class_ref while tsubsting.
	
	PR c++/16964
	* g++.dg/parse/error16.C: New test.
	
	PR c++/16904
	* g++.dg/template/error14.C: New test.
	
	PR c++/16929
	* g++.dg/template/error15.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.140&r2=1.3892.2.141
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.36&r2=1.157.2.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.36&r2=1.816.2.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.243&r2=1.3389.2.244
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/error16.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error14.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/error15.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-11 22:20 -------
Fixed in GCC 3.4.2.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

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

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-08-12 14:26 -------
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).


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

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

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-08-12 14:47 -------
Subject: Re:  [3.4/3.5 Regression] ICE on taking address of
 member in default parameter to member function

reichelt at gcc dot gnu dot org wrote:

>------- Additional Comments From reichelt at gcc dot gnu dot org  2004-08-12 14:26 -------
>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.



-- 


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

[Bug c++/16929] [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]

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

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

[mark at codesourcery dot com]

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

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

[reichelt at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |17011
              nThis|                            |


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

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

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-08-12 19:43 -------
The QoI issue is now tracked in PR 17011.
I already reopened the PR some comments ago. :-)


-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-29 18:06 -------
Postponed all ice-on-invalid bugs to GCC 3.4.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.2                       |3.4.3


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-12 12:48 -------
Lets close this as fixed as it is confusing to leave this bug open as the ICE has been fixed and QOI 
problem is PR 17011.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
      Known to fail|3.4.1 4.0                   |3.4.1
      Known to work|2.95 3.2 3.3                |2.95 3.2 3.3 4.0.0
         Resolution|                            |FIXED
   Target Milestone|3.4.3                       |3.4.2


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

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

[reichelt at gcc dot gnu dot org]

------- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-13 09:43 -------
Well, the QoI issue was not the only thing left in this PR.
The testcase in comment #8 shows an accepts-invalid bug that is not
just an QoI issue.

However, since this PR really is a little confusing now, I opened a
new PR for that issue, namely PR17971.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid             |


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