On 13.03.2016 21:03, Patrick Palka wrote:
Here we are mishandling the deferred_access_stack by not coherently
pushing/popping from it. In cp_parser_lambda_expression we are calling
(in order):
push_deferring_access_checks (dk_no_deferred);
cp_parser_start_tentative_firewall (parser);
...
pop_deferring_access_checks ();
cp_parser_end_tentative_firewall (parser, start, lambda_expr);
But the order of the last two popping calls does not correspond with the order
of the first two pushing calls. pop_deferring_access_checks should be
called last. This error may cause us to drop deferred access checks
instead of performing them.
Bootstrap + regtest in progress, does this look OK to commit if testing
succeeds?
when applying this patch to the gcc-5-branch I see regressions like
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:
In function 'void foo()':
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:6:8:
error: 'int X::i' is private
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:16:18:
error: within this context
Excess errors:
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:6:8:
error: 'int X::i' is private
/scratch/packages/gcc/5/gcc-5-5.3.1/src/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-70218.C:16:18:
error: within this context
haven't yet checked the trunk. I don't see any other regressions besides the
usual noise in the ubsan tests.
Matthias
