From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108542 invoked by alias); 3 May 2017 04:08:38 -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 108532 invoked by uid 89); 3 May 2017 04:08:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:WpsVuMR, H*f:sk:PM7g@ma X-HELO: sasl.smtp.pobox.com Received: from pb-smtp1.pobox.com (HELO sasl.smtp.pobox.com) (64.147.108.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 May 2017 04:08:35 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 402848CDE8; Wed, 3 May 2017 00:08:34 -0400 (EDT) Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 3661D8CDE6; Wed, 3 May 2017 00:08:34 -0400 (EDT) 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-smtp1.pobox.com (Postfix) with ESMTPSA id 5F6DF8CD93; Wed, 3 May 2017 00:08:33 -0400 (EDT) Subject: Re: [PATCH v4 0/12] [i386] Improve 64-bit Microsoft to System V ABI pro/epilogues To: JonY <10walls@gmail.com>, Uros Bizjak References: <49e81c0b-07a4-22df-d7c3-2439177ac7cf@pobox.com> Cc: gcc-patches , Jan Hubicka , Kai Tietz From: Daniel Santos Message-ID: <28651186-401b-91e0-7a63-add428967356@pobox.com> Date: Wed, 03 May 2017 04:32: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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2C9FF52E-2FB6-11E7-AECF-E680B56B9B0B-06139138!pb-smtp1.pobox.com X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00160.txt.bz2 On 05/02/2017 05:21 AM, JonY wrote: > On 05/01/2017 11:31 AM, Uros Bizjak wrote: > >> I also assume that Cygwin and MinGW people agree with the patch and >> the functionality itself. >> >> Uros. >> > Cygwin and MinGW does not use SysV/MS transitions directly in their own > code, changes should be OK. And to be clear, this did initially have a failed gcc test on Cygwin due to the aligned SSE MOVs portion of the patch set (this is the first three patches) and this is resolved by disabling that feature on SEH targets. This is the last two lines in the below chunk from 3/12: > @@ -14080,11 +14102,19 @@ ix86_expand_prologue (void) > GEN_INT (-align_bytes))); > > /* For the purposes of register save area addressing, the stack > - pointer is no longer valid. As for the value of sp_offset, > - see ix86_compute_frame_layout, which we need to match in order > - to pass verification of stack_pointer_offset at the end. */ > + pointer can no longer be used to access anything in the frame > + below m->fs.sp_realigned_offset and the frame pointer cannot be > + used for anything at or above. */ > m->fs.sp_offset = ROUND_UP (m->fs.sp_offset, align_bytes); > - m->fs.sp_valid = false; > + m->fs.sp_realigned = true; > + m->fs.sp_realigned_offset = m->fs.sp_offset - frame.nsseregs * 16; > + gcc_assert (m->fs.sp_realigned_offset == frame.stack_realign_offset); > + /* SEH unwind emit doesn't currently support REG_CFA_EXPRESSION, which > + is needed to describe where a register is saved using a realigned > + stack pointer, so we need to invalidate the stack pointer for that > + target. */ > + if (TARGET_SEH) > + m->fs.sp_valid = false; > } > > allocate = frame.stack_pointer_offset - m->fs.sp_offset; Still I have run complete tests on Cygwin with 32- and 64-bit using both the Cygwin and MinGW compilers. Daniel