http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
Bug ID: 60249 Summary: [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org The following invalid code snippet (compiled with "-std=c++11") triggers an ICE since GCC 4.7.0 (when user defined literals were introduced): ==================================== decltype( ""_ ) x; ==================================== The compiler goes into a loop and finally crashes: bug.cc:1:11: error: unable to find string literal operator 'operator""_' decltype( ""_ ) x; ^ bug.cc:1:11: warning: unknown escape sequence: '\257' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' [ snip more than a million lines ] bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: warning: unknown escape sequence: '\000' bug.cc:1:11: internal compiler error: Segmentation fault 0xba529f crash_signal ../../gcc/gcc/toplev.c:337 0x114a0f8 convert_escape ../../gcc/libcpp/charset.c:1271 0x114a0f8 cpp_interpret_string(cpp_reader*, cpp_string const*, unsigned long, cpp_string*, cpp_ttype) ../../gcc/libcpp/charset.c:1435 0x6a4f63 cp_parser_string_literal ../../gcc/gcc/cp/parser.c:3653 0x6afa21 cp_parser_primary_expression ../../gcc/gcc/cp/parser.c:4224 0x6b20dd cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:5971 0x6b50b6 cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7170 0x6b5ddf cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:7874 0x6b62d1 cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:8112 0x6b8684 cp_parser_expression ../../gcc/gcc/cp/parser.c:8274 0x6b36cd cp_parser_decltype_expr ../../gcc/gcc/cp/parser.c:11924 0x6b36cd cp_parser_decltype ../../gcc/gcc/cp/parser.c:12003 0x6cb40f cp_parser_simple_type_specifier ../../gcc/gcc/cp/parser.c:14533 0x6a942d cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:14380 0x6c2b40 cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:11547 0x6c9739 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:11137 0x6acc03 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:11086 0x6d3ea2 cp_parser_declaration ../../gcc/gcc/cp/parser.c:10983 0x6d2b98 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10869 0x6d443a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4014 Please submit a full bug report, [etc.] Although error-recovery bugs usually end up as P5, I'd vote for prioritizing this one higher: the amount of output (60 MB in my case) is worse than the crash.