From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57391 invoked by alias); 26 Jan 2016 14:34:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 57335 invoked by uid 89); 26 Jan 2016 14:34:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 26 Jan 2016 14:34:15 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 546EB344EC3 for ; Tue, 26 Jan 2016 14:34:14 +0000 (UTC) Received: from littlehelper.redhat.com (vpn1-4-110.ams2.redhat.com [10.36.4.110]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0QEYClc010638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 26 Jan 2016 09:34:13 -0500 From: Nick Clifton To: gcc-patches@gcc.gnu.org Subject: RFA: Fix for cygwin/mingw PR 66655 Date: Tue, 26 Jan 2016 14:34:00 -0000 Message-ID: <87lh7cv28r.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01983.txt.bz2 Hi Guys, The patch below is offered as a fix for PR 66655. In testing it appears that the patch does work, and does not break building libstdc++-v3 for cygwin or mingw. (Unlike the earlier version...) Due to my brain being so small, I have already checked the patch in, without receiving proper authorisation. I apologise for this. If the patch does prove suitable and is approved today, then I will leave it in. Otherwise I will revert the change and wait for proper approval. The patch itself is also slightly dubious in that I am not sure if I have all the correct terms in the if-statement. I was going for minimal impact on the current code, so I went for a set of selectors that matched the testcase for PR 66655, but nothing else. In particular I did not check to see if a similar problem exists for methods or virtual functions. My theory was that if does turn out that these kinds of functions can also trigger this kind of bug, then the patch could be extended later. Plus a new bug report is likely to include a new testcase that can be added to the testsuite. So ... OK to apply ? Cheers Nick gcc/ChangeLog 2016-01-26 Nick Clifton PR target/66655 * config/i386/winnt.c (i386_pe_binds_local_p): If a function has been marked as DECL_ONE_ONLY but we do not the means to make it so, then do not allow it to bind locally. Index: gcc/config/i386/winnt.c =================================================================== --- gcc/config/i386/winnt.c (revision 232784) +++ gcc/config/i386/winnt.c (working copy) @@ -341,6 +341,20 @@ && TREE_PUBLIC (exp) && DECL_EXTERNAL (exp)) return true; + +#ifndef MAKE_DECL_ONE_ONLY + /* PR target/66655: If a function has been marked as DECL_ONE_ONLY + but we do not the means to make it so, then do not allow it to + bind locally. */ + if (DECL_P (exp) + && TREE_CODE (exp) == FUNCTION_DECL + && TREE_PUBLIC (exp) + && DECL_ONE_ONLY (exp) + && ! DECL_EXTERNAL (exp) + && DECL_DECLARED_INLINE_P (exp)) + return false; +#endif + return default_binds_local_p_1 (exp, 0); }