[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3

["morpheby at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #31 from Ilya Mikhaltsou <morpheby at gmail dot com> ---
(In reply to James Clarke from comment #29)
> (In reply to Jack Howarth from comment #28)
> > I noticed that MacPorts is using…
> > 
> > #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) ||
> > __DARWIN_64_BIT_INO_T) 
> > 
> > and
> > 
> > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T 
> > 
> > rather than just…
> > 
> > 
> > 	#if SANITIZER_MAC && __DARWIN_64_BIT_INO_T 
> > 
> > and
> > 
> > # if __DARWIN_64_BIT_INO_T 
> > 
> > in their patch for gcc49…
> > 
> > https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10.
> > diff
> > 
> > Should we be doing the same?
> 
> That's because they're using my original patch from this bug report
> (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is
> based off Ilya Mikhaltsou's patch
> (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug
> report). I don't know why Ilya decided to default to a 64-bit dirent struct,
> as the documentation clearly states that it is only 64-bit when the
> _DARWIN_FEATURE_64_BIT_INODE macro is defined
> (https://developer.apple.com/library/mac/documentation/Darwin/Reference/
> ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from
> __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that
> _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when
> __DARWIN_64_BIT_INO_T is true.
> 
> Please note that I have updated my patch to use the public
> _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined
> rather than its value (seeing as the documentation only refers to its
> definition, not its value). The updated patches are at
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html.

I wasn't doing much thinking on the topic, I've simply made the minimal
necessary changes to a) compile on 10.10 and b) to work exactly the same as
before on previous versions. If you think it is redundant, there are no
objective reasons for keeping it that way.
>From gcc-bugs-return-459311-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 26 20:48:06 2014
Return-Path: <gcc-bugs-return-459311-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25209 invoked by alias); 26 Aug 2014 20:48:06 -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 25126 invoked by uid 48); 26 Aug 2014 20:48:03 -0000
From: "aaron.plavnick at spottradingllc dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62272] New: Gimplify throws error on method call from inside nested lambdas
Date: Tue, 26 Aug 2014 20:48: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.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: aaron.plavnick at spottradingllc dot com
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-62272-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-08/txt/msg01808.txt.bz2
Content-length: 3453

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

            Bug ID: 62272
           Summary: Gimplify throws error on method call from inside
                    nested lambdas
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aaron.plavnick at spottradingllc dot com

Here is a minimal code sample, the bug exists in 4.7.3, 4.8.2, and 4.9.1. I
compiled with -std=c++11

--------------------------------------------

template< typename T >
class B
{
    public:
        void Foo() {}

        void Bar()
        {
            [&]()
            {
                [&]() { Foo(); }();
            }();
        }
};

int main( int argc, char** argv )
{
    B<int> b;
    b.Bar();
    return 0;
}

----------------------

The compiler returns:

main.cpp: In lambda function:
main.cpp:11:34: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1741
                 [&]() { Foo(); }();
                                  ^
0x81b03d gimplify_var_or_parm_decl
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:1741
0x81d931 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:8058
0x81cb40 gimplify_modify_expr
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:4527
0x81d97a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:7627
0x820876 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:5373
0x820a3a gimplify_and_add
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:385
0x820a3a gimplify_init_ctor_eval
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:3558
0x81c0f2 gimplify_init_constructor
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:3904
0x81c98e gimplify_modify_expr_rhs
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:4167
0x81ca64 gimplify_modify_expr
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:4486
0x81d97a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:7627
0x81da18 gimplify_target_expr
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:5304
0x81da18 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:7994
0x81e4b3 gimplify_addr_expr
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:4833
0x81e4b3 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:7673
0x8235ba gimplify_call_expr
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:2395
0x81db82 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:7598
0x820876 gimplify_stmt(tree_node**, gimple_statement_base**)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:5373
0x81dc0a gimplify_cleanup_point_expr
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:5149
0x81dc0a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
        ../../../../src/gcc-4.9.1/gcc/gimplify.c:7990