Created attachment 23139 [details] test code compiler output: $ g++-4.5 -std=c++0x testcase.cpp testcase.cpp: In instantiation of 'decltype (int f(T(), "")) g(const T&) [with T = int, decltype (f(T(), "")) = int]': testcase.cpp:9:11: instantiated from here testcase.cpp:5:26: internal compiler error: in write_template_arg_literal, at cp/mangle.c:2687 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. tested version: 4.4.4-14ubuntu5 - Crash 4.5.1 - Crash 4.5.2 - Crash 4.5.6 20110127 - Crash
This c++98 variation using sizeof instead of decltype gives an ICE in the same place: template < typename T > int f( const T &, const char * ); template<int> struct N { }; template < typename T > N<sizeof( f( T(), "" ) )> g( const T &t ); void h() { g( 0 ); } This is a regression since 4.1 which doesn't ICE: testcase.cpp: In function 'void h()': testcase.cpp:11: sorry, unimplemented: call_expr cannot be mangled due to a defect in the C++ ABI
For this variation where f<T> is not deduced, 4.4 says "sorry, unimplemented" but doesn't ICE, 4.5 and 4.6 ICE in the same place: template < typename T > int f( const char * ); template<int> struct N { }; template < typename T > N<sizeof( f<T>( "" ) )> g( const T &t ); void h() { g( 0 ); }
(In reply to comment #2) > For this variation where f<T> is not deduced, 4.4 says "sorry, unimplemented" > but doesn't ICE, 4.5 and 4.6 ICE in the same place: > > template < typename T > > int f( const char * ); > > template<int> struct N { }; > > template < typename T > > N<sizeof( f<T>( "" ) )> g( const T &t ); > > void h() > { > g( 0 ); > } It is caused by revision 140120: http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00279.html
(In reply to comment #1) > This c++98 variation using sizeof instead of decltype gives an ICE in the same > place: > > template < typename T > > int f( const T &, const char * ); > > template<int> struct N { }; > > template < typename T > > N<sizeof( f( T(), "" ) )> g( const T &t ); > > void h() > { > g( 0 ); > } > > It is also caused by revision 140120: http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00279.html
So, the basic problem is that we still don't know how to mangle string constants, it just changed from a sorry to an ICE. There was a mangling proposed on the ABI list, but while looking at it I realized that it isn't sufficient--it produces a multiply defined symbol for template <typename T> constexpr T f(const T* p) { return p[0]; } template<int> struct N { }; template <typename T> void g(T, N<f((const T*)"1")>) { } template <typename T> void g(T, N<f((const T*)"2")>) { } int main() { g('1', N<'1'>()); g('2', N<'2'>()); }
Author: jason Date: Tue Mar 8 17:30:46 2011 New Revision: 170783 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170783 Log: PR c++/47488 * mangle.c (write_template_arg_literal) [STRING_CST]: Sorry. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c
I've checked in a patch to restore the sorry, but we still need to implement a mangling.
Author: jason Date: Tue Mar 8 17:39:10 2011 New Revision: 170785 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170785 Log: PR c++/47488 * mangle.c (write_template_arg_literal) [STRING_CST]: Sorry. Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/mangle.c
Author: jason Date: Tue Mar 8 17:40:27 2011 New Revision: 170786 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170786 Log: PR c++/47488 * mangle.c (write_template_arg_literal) [STRING_CST]: Sorry. Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/mangle.c
GCC 4.6.0 is being released, adjusting target milestone.
This problem still exists as of GCC 4.9.0 snapshot 20131013, with the same test case failing.
FWIW, the same test case still fails under GCC 7.2.0. Moreover, I ran into something-very-similar when playing with constexpr-function-of-string-literal-as-a-template-parameter; IMO, with advent of C++17 and constexpr functions this bug started to be significantly more important - please consider raising priority. Oh, and it does compile under Clang (at least Apple Clang 9.0.0).