[PATCH] Fix PR c++/70218 (illegal access to private field succeeds)

Patrick Palka patrick@parcs.ath.cx
Thu Mar 17 12:27:00 GMT 2016


On Wed, Mar 16, 2016 at 5:20 PM, Matthias Klose <doko@ubuntu.com> wrote:
> 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.

lambda-70218.C is the test case that this patch adds.  It looks like
GCC 5 and 6 report errors access errors that originate inside a lambda
slightly differently.  So I think the dg-error directives in
lambda-70218.C would just have to be trivially adjusted for a GCC 5
backport.



More information about the Gcc-patches mailing list