aboutsummaryrefslogtreecommitdiff
path: root/libcpp
diff options
context:
space:
mode:
authorJoseph Myers <josmyers@redhat.com>2024-11-27 22:27:08 +0000
committerJoseph Myers <josmyers@redhat.com>2024-11-27 22:27:08 +0000
commit87492fb3fd5e7510983e0275a38ba95769335018 (patch)
treea692b68da2b695c493e8c6a930ea5d6db78d7f67 /libcpp
parent73e5d2f87c257c2c12ee72fd4de9bdbb6a8e1aa9 (diff)
downloadgcc-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