From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38072 invoked by alias); 11 Feb 2017 03:36:52 -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 38056 invoked by uid 89); 11 Feb 2017 03:36:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=toolchains, H*f:sk:84cec90, Hx-languages-length:1704, collective X-HELO: sasl.smtp.pobox.com Received: from pb-smtp2.pobox.com (HELO sasl.smtp.pobox.com) (64.147.108.71) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 11 Feb 2017 03:36:41 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 8D48F68D7E; Fri, 10 Feb 2017 22:36:37 -0500 (EST) Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 85A7168D7D; Fri, 10 Feb 2017 22:36:37 -0500 (EST) Received: from [192.168.1.4] (unknown [76.215.41.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 9D50468D7C; Fri, 10 Feb 2017 22:36:36 -0500 (EST) Subject: Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues To: JonY <10walls@gmail.com>, Uros Bizjak References: <2fd14fe7-8d06-45ab-fb1e-96c9c8f4c03b@pobox.com> <84cec90b-bdcd-2859-ac5a-9b34335982e5@pobox.com> <5b7e6964-3875-55c2-caea-a95f36a466bb@gmail.com> Cc: gcc-patches , Jan Hubicka , Sandra Loosemore From: Daniel Santos Message-ID: <5352859a-ea66-1b91-c07c-79c5c56fff4a@pobox.com> Date: Sat, 11 Feb 2017 07:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5b7e6964-3875-55c2-caea-a95f36a466bb@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 4AB2E96C-F00B-11E6-B950-A7617B1B28F4-06139138!pb-smtp2.pobox.com X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00761.txt.bz2 On 02/10/2017 06:20 PM, JonY wrote: > On 02/10/2017 05:23 PM, Daniel Santos wrote: >> On 02/10/2017 05:34 AM, JonY wrote: >>> Hi, >>> mingw-w64 itself does not use any ms_abi/sysv_abi marked functions >>> internally, so it should be unaffected. I don't think Cygwin uses any >>> either, but I need to double check. >> Of course, ms_abi is gcc's default on Windows so it would be sysv_abi >> functions. I'm *guessing* that just about everything with Cygwin is >> built for Windows, but it would also make sense if (in some odd case) a >> binary built with sysv_abi is used by something and that library or >> program makes the ABI transition when using said hypothetical library. >> Even in these cases, I would not anticipate a problem, although any use >> of SEH would inhibit the optimization. Of course, I haven't *tested* >> this, so I'm only speaking from what I know. :) >> > Cygwin has internal functions marked ms_abi but none with sysv_abi, so > it will be unaffected by this change. Most 64bit mingw-w64 toolchains > are built with SEH for exception handling though, but since it is > disabled, it shouldn't break anything. > > If its not too much to ask, please do a gcc build targeting 32bit/64bit > mingw-w64 and Cygwin, it'll make solid evidence that the changes do not > break the compiler. > > Thanks. Will do. I'll even run a query afterwards and see if anything in Cygwin actually makes cross-ABI functions just for the sake of our collective curiosity. It's always nice to know. It is important that I make sure we don't break anything in Cygwin, being that I've mostly been thinking about Wine. Daniel