diff options
author | Joseph Myers <josmyers@redhat.com> | 2024-11-27 22:27:08 +0000 |
---|---|---|
committer | Joseph Myers <josmyers@redhat.com> | 2024-11-27 22:27:08 +0000 |
commit | 87492fb3fd5e7510983e0275a38ba95769335018 (patch) | |
tree | a692b68da2b695c493e8c6a930ea5d6db78d7f67 /libcpp | |
parent | 73e5d2f87c257c2c12ee72fd4de9bdbb6a8e1aa9 (diff) | |
download | gcc-87492fb3fd5e7510983e0275a38ba95769335018.zip gcc-87492fb3fd5e7510983e0275a38ba95769335018.tar.gz gcc-87492fb3fd5e7510983e0275a38ba95769335018.tar.bz2 |
c: Fix ICE using function name in parameter type in old-style function definition [PR91193]
As reported in bug 91193, if an old-style function definition
redeclares a typedef name as a function, then uses that function name
at the start of the first old-style parameter definition, then the
parser interprets that token as a typedef name (because lookahead
occurred before processing of the function declarator completed), but
when it is looked up in processing that parameter definition, what is
found is the redefinition, resulting in an ICE.
The function name's scope starts at the end of its declarator, so this
is similar to other cases where we call
c_parser_maybe_reclassify_token because lookahead might have
classified a token as being a typedef or not based on information from
the wrong scope; do so in this case as well, so resulting in the
expected parse errors from using something that's no longer a typedef
name as if it were a typedef name, and eliminating the ICE.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/91193
gcc/c/
* c-parser.cc (c_parser_maybe_reclassify_token): Define earlier.
(c_parser_declaration_or_fndef): Call
c_parser_maybe_reclassify_token before parsing old-style parameter
definitions.
gcc/testsuite/
* gcc.dg/pr91193-1.c, gcc.dg/pr91193-2.c: New tests.
Diffstat (limited to 'libcpp')
0 files changed, 0 insertions, 0 deletions