[Bug c++/57746] New: rejected valid specialization of member function of class template (I think)

[Bug c++/57746] New: rejected valid specialization of member function of class template (I think)

[luto at mit dot edu]

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

            Bug ID: 57746
           Summary: rejected valid specialization of member function of
                    class template (I think)
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luto at mit dot edu

Note: I could easily be wrong here...

template<typename T>
struct X
{
  static int val;
  static void func();
};

extern template struct X<int>;

template<> int X<int>::val = 5;  // OK
template<> void X<int>::func() {}  // Error

g++ 4.7.2 and some pre-4.8 build say "error: specialization of ‘static void
X<T>::func() [with T = int]’ after instantiation".  Oddly, both accept the
specialization of val.  clang++ rejects both.

The relevant part of the standard is probably [temp.explicit.4], which says:

A declaration of a function template, a member function or static data member
of a class template, or a member function template of a class or class template
shall precede an explicit instantiation of that entity. A definition of a class
template, a member class of a class template, or a member class template of a
class or class template shall precede an explicit instantiation of that entity
unless the explicit instantiation is preceded by an explicit specialization of
the entity with the same template arguments. If the declaration of the explicit
instantiation names an implicitly-declared special member function (Clause 12),
the program is ill-formed.

The two specializations are definitions, not declarations, as far as I know. 
Therefore, [temp.explicit.4] shouldn't apply.
>From gcc-bugs-return-425357-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 28 00:30:08 2013
Return-Path: <gcc-bugs-return-425357-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6040 invoked by alias); 28 Jun 2013 00:30:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5966 invoked by uid 48); 28 Jun 2013 00:30:04 -0000
From: "dscott at hmc dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57747] New: The progress indicator always shows 38%
Date: Fri, 28 Jun 2013 00:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dscott at hmc dot edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-57747-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01736.txt.bz2
Content-length: 1030

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW747

            Bug ID: 57747
           Summary: The progress indicator always shows 38%
           Product: gcc
           Version: 4.7.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dscott at hmc dot edu

We had a large project which repeatedly hit a compiler or linker error at 38%.
The build is managed by CMake, and worked correctly before we introduced the
bugs that caused the aforementioned compiler/linker errors.  We finally fixed
the bugs in our code, then re-ran CMake (clearing its cache), ran make clean,
and then ran make.  We were very confused to see the progress indicator always
read 38%.  We terminated compilation and did another make clean.  We then
allowed make to run all the way through --- and the build ran successfully from
start to finish.  However, at every single step along the way, the progress was
reported as 38%.

[Bug c++/57746] rejected valid specialization of member function of class template (I think)

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
According to the standard in general a definition is also a declaration
([basic.def] p2 "A declaration is a definition unless it declares a function
without specifying the function’s body (8.4), [..]"), therefore [temp.explicit]
applies here as well. 

I think that GCC is incorrect in not rejecting both cases, because the wording
clearly includes a "static data member of a class template" (This error still
exists in gcc 4.9 trunk).

I also think that the meaning of the code is well-defined only for C++11,
because in C++03 the concept of an explicit instantiation declaration did not
exist.
>From gcc-bugs-return-425420-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 29 13:45:24 2013
Return-Path: <gcc-bugs-return-425420-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2832 invoked by alias); 29 Jun 2013 13:45:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2792 invoked by uid 48); 29 Jun 2013 13:45:21 -0000
From: "harald at gigawatt dot nl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/57714] Newline rendered incorrectly in output
Date: Sat, 29 Jun 2013 13:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: harald at gigawatt dot nl
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57714-4-TT99fRqWzY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57714-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01799.txt.bz2
Content-length: 1397

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW714

--- Comment #16 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to David Krauss from comment #14)
> 1. Actually the C standard does care whether whitespace is added.

You're right for stringizing, but GCC already takes care to treat that as a
special case.

#define ID(x) x
#define STR(x) STR_(x)
#define STR_(x) #x
STR(ID(1)ID(2))ID(3)ID(4)

preprocesses to

"12"3 4

No space is inserted between the 1 and 2, because the C standard does not allow
that. No space is inserted between "12" and 3, because no space was present in
the input and no space is required. A space is inserted between 3 and 4 because
the preprocessed output would be misinterpreted otherwise.

> 2. Whitespace does not need to be added to cause the visual formatting of the output to match the input. The trick is to output a backslash character in the output.

A trailing backslash at the end of a line after preprocessing is a syntax error
and is treated as such by GCC. What you suggest requires running the result
through the preprocessor again in order to be able to compile the result. Note
that

int main() {
  ret\
urn 0;
}

is perfectly valid, but

#define ID(x) x
int main() {
  ID(ret)ID(\)
urn 0;
}

is not. If these become undistinguishable after preprocessing, it is impossible
to diagnose the syntax error, and that diagnostic is required.

[Bug c++/57746] rejected valid specialization of member function of class template (I think)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Daniel Krügler from comment #1)
> I also think that the meaning of the code is well-defined only for C++11,
> because in C++03 the concept of an explicit instantiation declaration did
> not exist.

It does for G++, it's been accepted as an extension in C++03 mode for years.
>From gcc-bugs-return-425469-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 30 12:46:19 2013
Return-Path: <gcc-bugs-return-425469-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19980 invoked by alias); 30 Jun 2013 12:46:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19938 invoked by uid 48); 30 Jun 2013 12:46:16 -0000
From: "mikpe at it dot uu.se" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57735] ICE with -mtune=xscale (error: could not split insn) when building webkit
Date: Sun, 30 Jun 2013 12:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikpe at it dot uu.se
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-57735-4-bkvacRROMW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57735-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57735-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01848.txt.bz2
Content-length: 832

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW735

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #4 from Mikael Pettersson <mikpe at it dot uu.se> ---
The ICE on the reduced test case started with r186147 and stopped with r199188.
They both touch the same code so I believe r199188 is a proper fix and not just
coincidental.  Backporting r199188 to current 4.8 branch fixes the ICE there
too,
but I haven't done a full bootstrap and regression test run on anything except
x86_64 yet.

r199188 did cause a regression (ICE on s390x), but the fix for that has already
been backported to 4.8 branch (at r199813).

[Bug c++/57746] rejected valid specialization of member function of class template (I think)

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Jonathan Wakely from comment #2)
> It does for G++, it's been accepted as an extension in C++03 mode for years.

What I actually meant to say with my comment is that for a proper bug report
the category should be C++11, because the argumentation of the bug report was
based on standard wording and not based on a gcc extension statement. Therefore
my own validation (e.g. when referring to gcc 4.9) did all happen with using
std=c++11.
>From gcc-bugs-return-425471-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 30 13:48:13 2013
Return-Path: <gcc-bugs-return-425471-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10846 invoked by alias); 30 Jun 2013 13:48:13 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10806 invoked by uid 48); 30 Jun 2013 13:48:07 -0000
From: "mikpe at it dot uu.se" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57504] invalid this pointer passed in call to virtual function that returns a struct
Date: Sun, 30 Jun 2013 13:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: mikpe at it dot uu.se
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-57504-4-LV8JlP3PyC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57504-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57504-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01850.txt.bz2
Content-length: 502

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW504

Mikael Pettersson <mikpe at it dot uu.se> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu.se

--- Comment #2 from Mikael Pettersson <mikpe at it dot uu.se> ---
I can reproduce the wrong-code with gcc-4.7.2 targeting x86_64-w64-mingw32
-m32, but not with a similarly configured gcc-4.7.3.

[Bug c++/57746] rejected valid specialization of member function of class template (I think)

[luto at mit dot edu]

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

--- Comment #4 from Andy Lutomirski <luto at mit dot edu> ---
Daniel, I'm unconvinced that your interpretation is the intended one. 
[temp.explicit].4 says "A declaration of [list including member function] ... A
definition of [list not including member function]".  If definitions were
intended to be declarations in this context, then the second part would be
redundant, I think.

Regardless, the interesting case is:

template<typename T>
struct X
{
  static int val;
  static void func();
};

// optionally: extern template struct X<int>;

void something()
{
  X<int>::func();
}

in one file and

struct X
{
  static int val;
  static void func();
};

template<> void X<int>::func() {}

in another.  I don't think this is an odr violation, since there is only one
definition of anything that could be confused with X<int>::func.  g++ will
happily compile and link it (without the extern template bit) and it will work.
 It is supposed to?  Could a conforming compiler mangle the specialized version
of func differently?

[Bug c++/57746] rejected valid specialization of member function of class template (I think)

[luto at mit dot edu]

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

--- Comment #6 from Andy Lutomirski <luto at mit dot edu> ---
Jonathan Wakely wrote in comment #4:
> (In reply to Andy Lutomirski from comment #4)
>> [temp.explicit].4 says "A declaration of [list including member function]
>> ... A definition of [list not including member function]".  If definitions
>> were intended to be declarations in this context, then the second part would
>> be redundant, I think.
>
> That doesn't follow at all. The second part describes different types of
> entities that have different requirements.
>
> For the first list an explicit instantiation must follow a declaration (and a
> definition also counts as a declaration) but for the second list an explicit
> instantiation must follow a definition, a declaration is not sufficient.

Ugh.  In that case, [temp.explicit].4 is irrelevant.  I guess it means that, if
you explicitly instantiate something, then a declaration and/or definition must
happen before that instantiation, and it probably doesn't mean that a
declaration and/or definition can't follow that explicit instantiation.

>> Regardless, the interesting case is:
>> 
>> template<typename T>
>> struct X
>> {
>>   static int val;
>>   static void func();
>> };
>> 
>> // optionally: extern template struct X<int>;
>> 
>> void something()
>> {
>>   X<int>::func();
>> }
>> 
>> in one file and
>> 
>> struct X
>> {
>>   static int val;
>>   static void func();
>> };
>> 
>> template<> void X<int>::func() {}
>> 
>> in another.  I don't think this is an odr violation, since there is only one
>> definition of anything that could be confused with X<int>::func.  g++ will
>> happily compile and link it (without the extern template bit) and it will
>> work.  It is supposed to?  Could a conforming compiler mangle the
>> specialized version of func differently?
>
> Isn't this ill-formed, with no diagnostic required, by both [temp] p6 and
> [temp.expl.spec] p6?

...so this proves that I know considerably less about C++ templates than I
thought I did.  Apparently even a translation unit containing exactly:

template<typename T> void func();

void caller()
{
  func<int>();
}

is ill-formed.  I wonder why.  g++ and clang++ both accept it, I think (from
memory) that MSVC accepts it as well, and I wouldn't be surprised if there are
quite a few libraries that rely on this behavior.

[Bug c++/57746] rejected valid specialization of member function of class template (I think)

[daniel.kruegler at googlemail dot com]

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

--- Comment #7 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Andy Lutomirski from comment #4)
> Daniel, I'm unconvinced that your interpretation is the intended one. 

Well, [temp.spec] p5 says more strongly that an explicit instantiation shall
only follow a declaration of an explicit specialization:

"For a given template and a given set of template-arguments,
— an explicit instantiation definition shall appear at most once in a program,
— an explicit specialization shall be defined at most once in a program
(according to 3.2), and
— both an explicit instantiation and a declaration of an explicit
specialization shall not appear in a program unless the explicit instantiation
follows a declaration of the explicit specialization.
An implementation is not required to diagnose a violation of this rule."

This is in agreement of my interpretation of [temp.explicit] p4.

> Regardless, the interesting case is:
> 
> template<typename T>
> struct X
> {
>   static int val;
>   static void func();
> };
> 
> // optionally: extern template struct X<int>;
> 
> void something()
> {
>   X<int>::func();
> }
> 
> in one file and
> 
> struct X
> {
>   static int val;
>   static void func();
> };
> 
> template<> void X<int>::func() {}

This code is not supported by the standard:

a) If the explicit instantiation declaration is provided, this violates above
quoted bullet 3 (you missed to declare the explicit specialization before). In
addition to that [temp.explicit] p11 requires the existence of an explicit
instantiation definition of X<int>::func():

"An entity that is the subject of an explicit instantiation declaration and
that is also used in a way that would otherwise cause an implicit instantiation
(14.7.1) in the translation unit shall be the subject of an explicit
instantiation definition somewhere in the program; otherwise the program is
ill-formed, no diagnostic required."

b) If the explicit instantiation declaration is *not* provided, X<int>::func()
is implicitly instantiated, but you provide an explicit instantiation instead.
This violates [temp.spec] p4:

"An instantiated template specialization can be either implicitly instantiated
(14.7.1) for a given argument list or be explicitly instantiated (14.7.2). A
specialization is a class, function, or class member that is either
instantiated or explicitly specialized (14.7.3)." 

More strongly, [temp.expl.spec] p6 says:

"If a template, a member template or a member of a class template is explicitly
specialized then that specialization shall be declared before the first use of
that specialization that would cause an implicit instantiation to take place,
in every translation unit in which such a use occurs; no diagnostic is
required."

You don't have the explicit specialization of  X<int>::func() declared in the
first TU that implicitly instantiates this member.
>From gcc-bugs-return-425620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 02 21:09:03 2013
Return-Path: <gcc-bugs-return-425620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16766 invoked by alias); 2 Jul 2013 21:09:03 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16713 invoked by uid 48); 2 Jul 2013 21:08:57 -0000
From: "luto at mit dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57746] Invalid specializations of member objects are accepted, unlike member functions
Date: Tue, 02 Jul 2013 21:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: luto at mit dot edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: short_desc
Message-ID: <bug-57746-4-DWW8kZX12w@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57746-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57746-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00127.txt.bz2
Content-length: 622

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW746

Andy Lutomirski <luto at mit dot edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|rejected valid              |Invalid specializations of
                   |specialization of member    |member objects are
                   |function of class template  |accepted, unlike member
                   |(I think)                   |functions

--- Comment #8 from Andy Lutomirski <luto at mit dot edu> ---
OK, I'm convinced.  I renamed the bug accordingly.

[Bug c++/57746] Invalid specializations of member objects are accepted, unlike member functions

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
GCC and clang reject the code.
ICC and MSVC accepts the code.