public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
@ 2020-03-13 20:51 ` jakub at gcc dot gnu.org
2020-03-17 20:22 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-13 20:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 48031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48031&action=edit
gcc10-pr90995.patch
Untested fix.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
2020-03-13 20:51 ` [Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024 jakub at gcc dot gnu.org
@ 2020-03-17 20:22 ` cvs-commit at gcc dot gnu.org
2020-03-17 20:22 ` [Bug c++/90995] [8/9 " jakub at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-03-17 20:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:cd0b71242738a1901405f421b352e4f6c30ff7c5
commit r10-7229-gcd0b71242738a1901405f421b352e4f6c30ff7c5
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Mar 17 21:21:16 2020 +0100
c++: Fix parsing of invalid enum specifiers [PR90995]
The testcase shows some accepts-invalid (the ones without alignas) and
ice-on-invalid-code (the ones with alignas) cases.
If the enum doesn't have an underlying type and is not a definition,
the caller retries to parse it as elaborated type specifier.
E.g. for enum struct S s it will then pedwarn that elaborated type
specifier
shouldn't have the struct/class keywords.
The problem is if the enum specifier is not followed by { when it has
underlying type. In that case we have already called
cp_parser_parse_definitely to end the tentative parsing started at the
beginning of cp_parser_enum_specifier. But the
cp_parser_error (parser, "expected %<;%> or %<{%>");
doesn't emit any error because the whole function is called from yet
another
tentative parse and the caller starts parsing the elaborated type
specifier where the cp_parser_enum_specifier stopped (i.e. after the
underlying type token(s)). The ultimate caller than commits the tentative
parsing (and even if it wouldn't, it wouldn't know what kind of error
to report). I think after seeing enum {,struct,class} : type not being
followed by { or ;, there is no reason not to report it right away, as it
can't be valid C++, which is what the patch does. Not sure if we shouldn't
also return error_mark_node instead of NULL_TREE, so that the caller
doesn't
try to parse it as elaborated type specifier (the patch doesn't do that
right now).
Furthermore, while reading the code, I've noticed that
parser->colon_corrects_to_scope_p is saved and set to false at the start
of the function, but not restored back in some cases. Don't have a
testcase
where this would be a problem, but it just seems wrong. Either we can in
the two spots replace return NULL_TREE; with { type = NULL_TREE; goto out;
}
or we could perhaps abuse warning_sentinel or create a special class with
dtor to clean the flag up.
And lastly, I've fixed some formatting issues in the function while reading
it.
2020-03-17 Jakub Jelinek <jakub@redhat.com>
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/90995] [8/9 Regression] ICE in grokdeclarator, at cp/decl.c:12024
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
2020-03-13 20:51 ` [Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024 jakub at gcc dot gnu.org
2020-03-17 20:22 ` cvs-commit at gcc dot gnu.org
@ 2020-03-17 20:22 ` jakub at gcc dot gnu.org
2020-04-07 19:03 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-03-17 20:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in
|grokdeclarator, at |grokdeclarator, at
|cp/decl.c:12024 |cp/decl.c:12024
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/90995] [8/9 Regression] ICE in grokdeclarator, at cp/decl.c:12024
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2020-03-17 20:22 ` [Bug c++/90995] [8/9 " jakub at gcc dot gnu.org
@ 2020-04-07 19:03 ` cvs-commit at gcc dot gnu.org
2020-04-07 20:00 ` [Bug c++/90995] [8 " jakub at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-07 19:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:980a7a0be5a114e285c49ab05ac70881e4f27fc3
commit r9-8462-g980a7a0be5a114e285c49ab05ac70881e4f27fc3
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Mar 17 21:21:16 2020 +0100
c++: Fix parsing of invalid enum specifiers [PR90995]
The testcase shows some accepts-invalid (the ones without alignas) and
ice-on-invalid-code (the ones with alignas) cases.
If the enum doesn't have an underlying type and is not a definition,
the caller retries to parse it as elaborated type specifier.
E.g. for enum struct S s it will then pedwarn that elaborated type
specifier
shouldn't have the struct/class keywords.
The problem is if the enum specifier is not followed by { when it has
underlying type. In that case we have already called
cp_parser_parse_definitely to end the tentative parsing started at the
beginning of cp_parser_enum_specifier. But the
cp_parser_error (parser, "expected %<;%> or %<{%>");
doesn't emit any error because the whole function is called from yet
another
tentative parse and the caller starts parsing the elaborated type
specifier where the cp_parser_enum_specifier stopped (i.e. after the
underlying type token(s)). The ultimate caller than commits the tentative
parsing (and even if it wouldn't, it wouldn't know what kind of error
to report). I think after seeing enum {,struct,class} : type not being
followed by { or ;, there is no reason not to report it right away, as it
can't be valid C++, which is what the patch does. Not sure if we shouldn't
also return error_mark_node instead of NULL_TREE, so that the caller
doesn't
try to parse it as elaborated type specifier (the patch doesn't do that
right now).
Furthermore, while reading the code, I've noticed that
parser->colon_corrects_to_scope_p is saved and set to false at the start
of the function, but not restored back in some cases. Don't have a
testcase
where this would be a problem, but it just seems wrong. Either we can in
the two spots replace return NULL_TREE; with { type = NULL_TREE; goto out;
}
or we could perhaps abuse warning_sentinel or create a special class with
dtor to clean the flag up.
And lastly, I've fixed some formatting issues in the function while reading
it.
2020-03-17 Jakub Jelinek <jakub@redhat.com>
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/90995] [8 Regression] ICE in grokdeclarator, at cp/decl.c:12024
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2020-04-07 19:03 ` cvs-commit at gcc dot gnu.org
@ 2020-04-07 20:00 ` jakub at gcc dot gnu.org
2020-09-17 14:25 ` cvs-commit at gcc dot gnu.org
2020-09-17 17:12 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-04-07 20:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
|grokdeclarator, at |grokdeclarator, at
|cp/decl.c:12024 |cp/decl.c:12024
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 9.4+ too.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/90995] [8 Regression] ICE in grokdeclarator, at cp/decl.c:12024
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2020-04-07 20:00 ` [Bug c++/90995] [8 " jakub at gcc dot gnu.org
@ 2020-09-17 14:25 ` cvs-commit at gcc dot gnu.org
2020-09-17 17:12 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-09-17 14:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:feb0b5e3339e3b3f710c4f82d5997c1cd6af67ae
commit r8-10469-gfeb0b5e3339e3b3f710c4f82d5997c1cd6af67ae
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Mar 17 21:21:16 2020 +0100
c++: Fix parsing of invalid enum specifiers [PR90995]
The testcase shows some accepts-invalid (the ones without alignas) and
ice-on-invalid-code (the ones with alignas) cases.
If the enum doesn't have an underlying type and is not a definition,
the caller retries to parse it as elaborated type specifier.
E.g. for enum struct S s it will then pedwarn that elaborated type
specifier
shouldn't have the struct/class keywords.
The problem is if the enum specifier is not followed by { when it has
underlying type. In that case we have already called
cp_parser_parse_definitely to end the tentative parsing started at the
beginning of cp_parser_enum_specifier. But the
cp_parser_error (parser, "expected %<;%> or %<{%>");
doesn't emit any error because the whole function is called from yet
another
tentative parse and the caller starts parsing the elaborated type
specifier where the cp_parser_enum_specifier stopped (i.e. after the
underlying type token(s)). The ultimate caller than commits the tentative
parsing (and even if it wouldn't, it wouldn't know what kind of error
to report). I think after seeing enum {,struct,class} : type not being
followed by { or ;, there is no reason not to report it right away, as it
can't be valid C++, which is what the patch does. Not sure if we shouldn't
also return error_mark_node instead of NULL_TREE, so that the caller
doesn't
try to parse it as elaborated type specifier (the patch doesn't do that
right now).
Furthermore, while reading the code, I've noticed that
parser->colon_corrects_to_scope_p is saved and set to false at the start
of the function, but not restored back in some cases. Don't have a
testcase
where this would be a problem, but it just seems wrong. Either we can in
the two spots replace return NULL_TREE; with { type = NULL_TREE; goto out;
}
or we could perhaps abuse warning_sentinel or create a special class with
dtor to clean the flag up.
And lastly, I've fixed some formatting issues in the function while reading
it.
2020-03-17 Jakub Jelinek <jakub@redhat.com>
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
(cherry picked from commit 980a7a0be5a114e285c49ab05ac70881e4f27fc3)
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug c++/90995] [8 Regression] ICE in grokdeclarator, at cp/decl.c:12024
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2020-09-17 14:25 ` cvs-commit at gcc dot gnu.org
@ 2020-09-17 17:12 ` jakub at gcc dot gnu.org
6 siblings, 0 replies; 7+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-09-17 17:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90995
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 8.5 too.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-09-17 17:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-90995-4@http.gcc.gnu.org/bugzilla/>
2020-03-13 20:51 ` [Bug c++/90995] [8/9/10 Regression] ICE in grokdeclarator, at cp/decl.c:12024 jakub at gcc dot gnu.org
2020-03-17 20:22 ` cvs-commit at gcc dot gnu.org
2020-03-17 20:22 ` [Bug c++/90995] [8/9 " jakub at gcc dot gnu.org
2020-04-07 19:03 ` cvs-commit at gcc dot gnu.org
2020-04-07 20:00 ` [Bug c++/90995] [8 " jakub at gcc dot gnu.org
2020-09-17 14:25 ` cvs-commit at gcc dot gnu.org
2020-09-17 17:12 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).