[Bug c++/58972] New: Lambda can't access private members

[Bug c++/58972] New: Lambda can't access private members

[akim.demaille at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

            Bug ID: 58972
           Summary: Lambda can't access private members
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: akim.demaille at gmail dot com

Hi all,

Again, this problem report might be bogus.  IANALL and reading the proposed
standard did not really help me understand if the problem is in the compiler,
or in the eye of the beholder.

Anyway, I think that if this is not a problem of G++, it is one of C++.  At
least Clang++ (3.4) accepts it.

$ cat foo.cc
class base
{
protected:
  using type = int;
};

template <typename T>
class derive: public base
{
  using typename base::type;
public:
  void foo(type a)
  {
    auto f = [a](type x){ return x == a; };
    f(32);
  }
};

int main()
{
  derive<char> d;
  d.foo(23);
}
$ clang++-mp-3.4 -std=c++11 foo.cc
$ g++-mp-4.9 --version
g++-mp-4.9 (MacPorts gcc49 4.9-20130915_0) 4.9.0 20130915 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-mp-4.9 -std=c++11 foo.cc
foo.cc: In instantiation of 'struct derive<T>::foo(base::type) [with T = char;
base::type = int]::<lambda(using type = int)>':
foo.cc:14:42:   required from 'void derive<T>::foo(base::type) [with T = char;
base::type = int]'
foo.cc:22:11:   required from here
foo.cc:4:19: error: 'using type = int' is protected
   using type = int;
                   ^
foo.cc:14:18: error: within this context
     auto f = [a](type x){ return x == a; };
                  ^
$ g++-mp-4.8 --version
g++-mp-4.8 (MacPorts gcc48 4.8.1_3) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++-mp-4.8 -std=c++11 foo.cc
foo.cc: In instantiation of 'struct derive<T>::foo(base::type) [with T = char;
base::type = int]::__lambda0':
foo.cc:14:42:   required from 'void derive<T>::foo(base::type) [with T = char;
base::type = int]'
foo.cc:22:11:   required from here
foo.cc:4:19: error: 'using type = int' is protected
   using type = int;
                   ^
foo.cc:14:18: error: within this context
     auto f = [a](type x){ return x == a; };
                  ^

FWIW, if derived is no longer template, it works.

BTW, someone should have a look at this:
http://stackoverflow.com/questions/11933999/why-is-it-not-possible-to-use-private-method-in-a-lambda
(and especially http://ideone.com/DJezf).  Maybe it's the same issue, maybe
it's slightly different, but again, clang++ eats it.

[Bug c++/58972] Lambda can't access private members

[daniel.kruegler at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
The behaviour looks like a gcc defect to me, not as a language problem. Note
that the similar code using a local class type causes the same kind of problem
for gcc:

//-------------------
class base
{
protected:
  typedef int type;
};

template <typename T>
class derive: public base
{
  using typename base::type;
public:
  void foo(type a)
  {
     struct f_t {
      f_t(type a) : a(a) {}
      bool operator()(type x) const { return x == a; }
      type a;
    } f(a);
    f(32);
  }
};

int main()
{
  derive<char> d;
  d.foo(23);
}
//-------------------

It seems to be a regression, because gcc 4.4.6 and earlier accepted the code.
According to 9.8 [class.local] p1 the wording says that it should be
well-formed:

"The local class is in the scope of the enclosing scope, and has the same
access to names outside the function as does the enclosing function."
>From gcc-bugs-return-433351-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Nov 03 14:58:02 2013
Return-Path: <gcc-bugs-return-433351-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32720 invoked by alias); 3 Nov 2013 14:58:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 32343 invoked by uid 48); 3 Nov 2013 14:55:58 -0000
From: "reichelt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58979] New: [4.8/4.9 Regression] ICE with invalid use of pointer-to-member
Date: Sun, 03 Nov 2013 14:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: reichelt at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-58979-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg00128.txt.bz2
Content-length: 2229

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX979

            Bug ID: 58979
           Summary: [4.8/4.9 Regression] ICE with invalid use of
                    pointer-to-member
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: reichelt at gcc dot gnu.org

The following invalid line of code triggers an ICE since GCC 4.8.0:

=======================int i = 0->*0;
=======================
bug.cc:1:13: internal compiler error: in invalid_indirection_error, at
c-family/c-common.c:9943
 int i = 0->*0;
             ^
0x77c793 invalid_indirection_error(unsigned int, tree_node*, ref_operator)
        ../../gcc/gcc/c-family/c-common.c:9943
0x6857c4 cp_build_indirect_ref(tree_node*, ref_operator, int)
        ../../gcc/gcc/cp/typeck.c:2976
0x558424 build_new_op_1
        ../../gcc/gcc/cp/call.c:5489
0x558b57 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
        ../../gcc/gcc/cp/call.c:5513
0x679012 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
        ../../gcc/gcc/cp/typeck.c:3752
0x6523b5 cp_parser_binary_expression
        ../../gcc/gcc/cp/parser.c:7920
0x65260f cp_parser_assignment_expression
        ../../gcc/gcc/cp/parser.c:8039
0x652a74 cp_parser_assignment_expression
        ../../gcc/gcc/cp/parser.c:8089
0x652a74 cp_parser_constant_expression
        ../../gcc/gcc/cp/parser.c:8299
0x663f06 cp_parser_init_declarator
        ../../gcc/gcc/cp/parser.c:16645
0x66552f cp_parser_simple_declaration
        ../../gcc/gcc/cp/parser.c:11107
0x6494e0 cp_parser_block_declaration
        ../../gcc/gcc/cp/parser.c:10988
0x6707d7 cp_parser_declaration
        ../../gcc/gcc/cp/parser.c:10885
0x66f4f8 cp_parser_declaration_seq_opt
        ../../gcc/gcc/cp/parser.c:10771
0x670e36 cp_parser_translation_unit
        ../../gcc/gcc/cp/parser.c:4007
0x670e36 c_parse_file()
        ../../gcc/gcc/cp/parser.c:31045
0x791113 c_common_parse_file()
        ../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ville.voutilainen at gmail dot com

--- Comment #2 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Uh oh. The current trunk ICEs with Daniel's code, but compiles Akim's testcase
correctly.

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6112 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

--- Comment #3 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
[ville@localhost ~]$ g++ --std=c++11 -c dan.cpp 
dan.cpp: In instantiation of ‘struct derive<T>::foo(base::type) [with T = char;
base::type = int]::f_t’:
dan.cpp:18:5:   required from ‘void derive<T>::foo(base::type) [with T = char;
base::type = int]’
dan.cpp:26:11:   required from here
dan.cpp:4:15: error: ‘typedef int base::type’ is protected
   typedef int type;
               ^
dan.cpp:15:11: error: within this context
       f_t(type a) : a(a) {}
           ^
dan.cpp: In instantiation of ‘void derive<T>::foo(base::type) [with T = char;
base::type = int]’:
dan.cpp:26:11:   required from here
dan.cpp:18:10: internal compiler error: in instantiate_decl, at cp/pt.c:19746
     } f(a);
          ^
0x5c281f instantiate_decl(tree_node*, int, bool)
    ../../gcc/cp/pt.c:19745
0x638853 mark_used(tree_node*, int)
    ../../gcc/cp/decl2.c:5016
0x553bf3 build_over_call
    ../../gcc/cp/call.c:7325
0x55f470 build_new_method_call_1
    ../../gcc/cp/call.c:8037
0x55f470 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
    ../../gcc/cp/call.c:8107
0x560549 build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
    ../../gcc/cp/call.c:7651
0x6bd6e9 expand_default_init
    ../../gcc/cp/init.c:1713
0x6bd6e9 expand_aggr_init_1
    ../../gcc/cp/init.c:1814
0x6bfdac build_aggr_init(tree_node*, tree_node*, int, int)
    ../../gcc/cp/init.c:1566
0x57360c build_aggr_init_full_exprs
    ../../gcc/cp/decl.c:5642
0x57360c check_initializer
    ../../gcc/cp/decl.c:5777
0x58556c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
    ../../gcc/cp/decl.c:6445
0x5c9700 tsubst_expr
    ../../gcc/cp/pt.c:13650
0x5c5d83 tsubst_expr
    ../../gcc/cp/pt.c:13538
0x5c6a13 tsubst_expr
    ../../gcc/cp/pt.c:13724
0x5c401b instantiate_decl(tree_node*, int, bool)
    ../../gcc/cp/pt.c:20036
0x5fce67 instantiate_pending_templates(int)
    ../../gcc/cp/pt.c:20152
0x63a29f cp_write_global_declarations()
    ../../gcc/cp/decl2.c:4348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>From gcc-bugs-return-453140-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 03 21:45:10 2014
Return-Path: <gcc-bugs-return-453140-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13797 invoked by alias); 3 Jun 2014 21:45:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13775 invoked by uid 48); 3 Jun 2014 21:45:07 -0000
From: "adam at aphirst dot karoo.co.uk" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61406] New: ICE on ASSOCIATE construct to literal array expression
Date: Tue, 03 Jun 2014 21:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: adam at aphirst dot karoo.co.uk
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-61406-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00222.txt.bz2
Content-length: 1836

https://gcc.gnu.org/bugzilla/show_bug.cgi?ida406

            Bug ID: 61406
           Summary: ICE on ASSOCIATE construct to literal array expression
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adam at aphirst dot karoo.co.uk

Created attachment 32885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id2885&actioníit
demonstration of ICE for ASSOCIATE with array literal

Association of a name to a literal array expression (see attached test case)
results in an ICE.

I'm sure that this used to work in GCC 4.8 (at least, it seems to in the
mingw32 setup of 4.8 that I have at work, and on a friend's 4.6), but not here
in 4.9.0.

Compiled using `gfortran -Wall -Wextra -stdò008`. No optimisations.

Arch Linux x86_64

-----
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.9-20140521/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-cloog-version-check --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--enable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.0 20140521 (prerelease) (GCC)

[Bug c++/58972] Lambda can't access private members

[akim.demaille at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

--- Comment #4 from Akim Demaille <akim.demaille at gmail dot com> ---
Could someone confirm this bug?  The 4.9 I have does not ICEs and still refuses
both sources.

akim@erebus /tmp $ g++-mp-4.9 --version                                        
      13:12:11
g++-mp-4.9 (MacPorts gcc49 4.9-20140416_2) 4.9.0 20140416 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c++/58972] Lambda can't access private members

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Seems to be fixed on trunk, probably by Ville's fix for protected members.

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

--- Comment #6 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Jonathan Wakely from comment #5)
> Seems to be fixed on trunk, probably by Ville's fix for protected members.

Yes, that fix is for 59483, I didn't wish to have these as duplicates
because while the original problem of this bug report is fixed by the
same patch, we need to look at the ICE separately, since it's unrelated.
If someone wants, we could rip that out to a separate bug and close this
one as RESOLVED.

[Bug c++/58972] Lambda can't access private members

[daniel.kruegler at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

--- Comment #7 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Ville Voutilainen from comment #6)
Makes sense to me, I'll do that for the local-class example
>From gcc-bugs-return-455018-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 26 12:28:27 2014
Return-Path: <gcc-bugs-return-455018-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11186 invoked by alias); 26 Jun 2014 12:28:26 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11128 invoked by uid 48); 26 Jun 2014 12:28:18 -0000
From: "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9
Date: Thu, 26 Jun 2014 12:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pault at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-60898-4-CmTer1xyzE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60898-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60898-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg02100.txt.bz2
Content-length: 860

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`898

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #4)
> > After providing all the missing 'USE' items:
>
> Where did you get them?

Dear Jerry,

Dominique's question is sort of... well, necessary since there are no namelist
declarations in the source provided.

Could you either reduce the source to a testcase or post the missing bits,
please?

I presume that, since the problem is with a declaration, the enclosing program
unit by itself will be enough to generate the ICE.

Cheers

Paul

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-12
                 CC|                            |jason at redhat dot com
     Ever confirmed|0                           |1

--- Comment #8 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Does not ICE anymore, and the original bug has been resolved (Daniel's local
class example is still rejected). I don't know which revision fixes it, though.
:)

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

--- Comment #9 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to Ville Voutilainen from comment #8)
> Does not ICE anymore, and the original bug has been resolved (Daniel's local
> class example is still rejected). I don't know which revision fixes it,
> though. :)

Clarification - the original aka the lambda case is fixed by the fix for 59483,
the local class example is a separate bug.

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|ville.voutilainen at gmail dot com |jason at redhat dot com

--- Comment #12 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Jason, please pick this up, fixing this is beyond my capabilities and I am
doing library stuff atm.

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

--- Comment #13 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Looks like the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957
may have fixed this one, too.

[Bug c++/58972] Lambda can't access private members

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jason at gcc dot gnu.org
         Resolution|---                         |FIXED
           Assignee|jason at redhat dot com            |jason at gcc dot gnu.org
   Target Milestone|---                         |6.0

--- Comment #14 from Jason Merrill <jason at gcc dot gnu.org> ---
Yep, fixed for GCC 6.