Bug 60249 - [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals
Summary: [c++11] Compiler goes into semi-infinite loop with wrong usage of user define...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog, ice-on-invalid-code
Depends on:
Blocks:
 
Reported: 2014-02-17 21:18 UTC by Volker Reichelt
Modified: 2014-07-01 05:32 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.7.0, 4.8.0, 4.9.0
Last reconfirmed:


Attachments
Patch 58781, 59867, 60249, ... (1.22 KB, patch)
2014-06-27 21:36 UTC, Ed Smith-Rowland
Details | Diff
CL_from_hell (237 bytes, text/plain)
2014-06-28 13:28 UTC, Ed Smith-Rowland
Details
patch_from_hell (1.22 KB, text/plain)
2014-06-28 13:28 UTC, Ed Smith-Rowland
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Volker Reichelt 2014-02-17 21:18:37 UTC
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.
Comment 1 Paolo Carlini 2014-04-17 13:38:39 UTC
Maybe Ed can have a look.
Comment 2 Paolo Carlini 2014-06-25 17:45:26 UTC
Ed?
Comment 3 Ed Smith-Rowland 2014-06-26 14:51:33 UTC
On 06/25/2014 01:45 PM, paolo.carlini at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
>
> --- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
> Ed?
>
Paolo,
I'm really struggling with this and some decltype ud literal bugs that I 
think are related.
I'll give it a last look today.
I may have to get some help.
I'll be more exact about where I am stuck tonight.
I'm having trouble getting time to work on these.
Ed
Comment 4 Ed Smith-Rowland 2014-06-27 21:36:13 UTC
Created attachment 33022 [details]
Patch 58781, 59867, 60249, ...

I think I got it.

Don't mess with the token stream.

PR C++/58781 - Unicode strings broken in a strange way
PR C++/59867 - Template string literal loses first symbol
PR C++/60249 - Compiler goes into semi-infinite loop with wrong usage of user defined string literals
Plus I fixed an misleading error message for string literal operator templates (not available in C++11).
Comment 5 Paolo Carlini 2014-06-27 21:39:27 UTC
Patch looks *great*. If it works, please send it to mailing list ASAP.
Comment 6 Ed Smith-Rowland 2014-06-28 13:28:24 UTC
Created attachment 33025 [details]
CL_from_hell

On 06/27/2014 05:39 PM, paolo.carlini at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
>
> --- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
> Patch looks *great*. If it works, please send it to mailing list ASAP.
>
I think I finally got these weird user-defined string literal bugs. 
"Don't cross the streams!"

Dr. Egon Spengler

PR C++/58781  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58781>  - Unicode strings broken in a strange way
PR C++/59867  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867>  - Template string literal loses first symbol
PR C++/60249  <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249>  - Compiler goes into semi-infinite loop with wrong usage of user defined string literals
Plus I fixed an misleading error message for string literal operator templates (not available in C++11).

Built and tested clean on x86_64-linux.

OK?

I would also like to apply this to 4.9.
Comment 7 Ed Smith-Rowland 2014-06-28 13:28:27 UTC
Created attachment 33026 [details]
patch_from_hell
Comment 8 Paolo Carlini 2014-06-28 14:03:39 UTC
Thanks, but in general I would recommend sending patches to gcc-patches in a separate email, with a clear [C++ Patch] or something similar in the subject. Also, please minimize jokes and other redundant content, we already have setious issues with lost patches, old bugs remaining umfixed for ages, etc, without.
Comment 9 Ed Smith-Rowland 2014-06-28 14:21:39 UTC
On 06/28/2014 10:03 AM, paolo.carlini at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
>
> --- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
> Thanks, but in general I would recommend sending patches to gcc-patches in a
> separate email, with a clear [C++ Patch] or something similar in the subject.
> Also, please minimize jokes and other redundant content, we already have
> setious issues with lost patches, old bugs remaining umfixed for ages, etc,
> without.
>
Sorry about the noise.
Should I send a new cleaner message with new subject?
Comment 10 Ed Smith-Rowland 2014-06-28 14:48:08 UTC
On 06/28/2014 10:03 AM, paolo.carlini at oracle dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249
>
> --- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
> Thanks, but in general I would recommend sending patches to gcc-patches in a
> separate email, with a clear [C++ Patch] or something similar in the subject.
> Also, please minimize jokes and other redundant content, we already have
> setious issues with lost patches, old bugs remaining umfixed for ages, etc,
> without.
>

Sorry about the noise.
Should I send a new cleaner message with new subject?
Comment 11 Ed Smith-Rowland 2014-07-01 03:13:49 UTC
Author: emsr
Date: Tue Jul  1 03:13:17 2014
New Revision: 212186

URL: https://gcc.gnu.org/viewcvs?rev=212186&root=gcc&view=rev
Log:
cp/

2014-06-28  Edward Smith-Rowland  <3dw4rd@verizon.net>

	PR c++/58781
	PR c++/60249
	PR c++/59867
	* parser.c (cp_parser_userdef_string_literal()): Take a tree
	not a cp_token*. (cp_parser_string_literal(): Don't hack
	the token stream!


testsuite/

2014-06-28  Edward Smith-Rowland  <3dw4rd@verizon.net>

	PR c++/58781
	PR c++/60249
	PR c++/59867
	* testsuite/g++.dg/cpp0x/pr58781.C: New.
	* testsuite/g++.dg/cpp0x/pr60249.C: New.
	* testsuite/g++.dg/cpp1y/pr59867.C: New.



Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/pr58781.C
    trunk/gcc/testsuite/g++.dg/cpp0x/pr60249.C
    trunk/gcc/testsuite/g++.dg/cpp1y/pr59867.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c
    trunk/gcc/testsuite/ChangeLog
Comment 12 Ed Smith-Rowland 2014-07-01 05:31:07 UTC
Author: emsr
Date: Tue Jul  1 05:30:34 2014
New Revision: 212188

URL: https://gcc.gnu.org/viewcvs?rev=212188&root=gcc&view=rev
Log:
cp/

2014-06-28  Edward Smith-Rowland  <3dw4rd@verizon.net>

	PR c++/58781
	PR c++/60249
	PR c++/59867
	* parser.c (cp_parser_userdef_string_literal()): Take a tree
	not a cp_token*. (cp_parser_string_literal(): Don't hack
	the token stream!

testsuite/

2014-06-28  Edward Smith-Rowland  <3dw4rd@verizon.net>

	PR c++/58781
	PR c++/60249
	PR c++/59867
	* testsuite/g++.dg/cpp0x/pr58781.C: New.
	* testsuite/g++.dg/cpp0x/pr60249.C: New.
	* testsuite/g++.dg/cpp1y/pr59867.C: New.


Added:
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/pr58781.C
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/pr60249.C
    branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp1y/pr59867.C
Modified:
    branches/gcc-4_9-branch/gcc/cp/ChangeLog
    branches/gcc-4_9-branch/gcc/cp/parser.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
Comment 13 Ed Smith-Rowland 2014-07-01 05:32:42 UTC
Fixed.