On Thu, 12 Nov 2015, Marek Polacek wrote: > As explained in the PR, the issue here was that we were treating a TYPENAME > wrongly as an ID. That happened because we were using information from the > wrong scope when parsing a token after an else clause. I.e. in fn1 in the > attached testcase we need to examine the token after "if (1);" to see if it's > the "else" keyword, but when it's not, we use the scope of the for loop when > classifying the token, so we wrongly see "T" as a identifier of a variable. > Fixed by examining the token again and reclassifying it. > > Moreover, we were ICEing in a similar scenario, treating ID as a TYPENAME, as > demonstrated in pr67784-2.c. The fix is analogical. > > Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK. -- Joseph S. Myers jos...@codesourcery.com
