From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46453 invoked by alias); 13 Mar 2017 18:40:34 -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 46366 invoked by uid 89); 13 Mar 2017 18:40:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=gotten 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; Mon, 13 Mar 2017 18:40:28 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 88532810CD; Mon, 13 Mar 2017 14:40:25 -0400 (EDT) Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 81EC7810CC; Mon, 13 Mar 2017 14:40:25 -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-smtp2.pobox.com (Postfix) with ESMTPSA id BE69E810CB; Mon, 13 Mar 2017 14:40:24 -0400 (EDT) Subject: Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues To: 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 , JonY <10walls@gmail.com> From: Daniel Santos Message-ID: <6f0a90d1-1fbb-9ce8-1dea-9caa76fc994a@pobox.com> Date: Mon, 13 Mar 2017 18:40: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: 857EC6C8-081C-11E7-92C6-FC50AE2156B6-06139138!pb-smtp2.pobox.com X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00671.txt.bz2 Uros, Testing on Cygwin only turns out to be a nightmare, but I've finally gotten some test results that I'm calling "clean enough". I have only done 64-bit Cygwin thus far, (still need 32-bit Cygwin as well as 32/64 MinGW), but I've hit a snag. The first patch set ("Use aligned SSE movs for re-aligned MS ABI pro/epilogues" -- https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01859.html) modifies how we select a base register and offset for accessing the stack. The test gcc.target/x86_64/abi/callabi/vaarg-5a.c uses a realigned stack pointer in a cross-abi case that triggers an internal compiler error at config/i386/winnt.c:1132 where i386_pe_seh_unwind_emit() doesn't like REG_CFA_EXPRESSION in the notes. This is the snippet: for (note = REG_NOTES (insn); note ; note = XEXP (note, 1)) { switch (REG_NOTE_KIND (note)) { case REG_FRAME_RELATED_EXPR: pat = XEXP (note, 0); goto found; case REG_CFA_DEF_CFA: case REG_CFA_EXPRESSION: /* Only emitted with DRAP, which we disable. */ gcc_unreachable (); break; This is the chunk that introduces this new behavior: @@ -12824,6 +12878,13 @@ ix86_emit_save_reg_using_mov (machine_mode mode, unsigned int regno, } } + else if (base == stack_pointer_rtx && m->fs.sp_realigned + && cfa_offset >= m->fs.sp_realigned_offset) + { + gcc_checking_assert (stack_realign_fp); + add_reg_note (insn, REG_CFA_EXPRESSION, gen_rtx_SET (mem, reg)); + } + /* The memory may not be relative to the current CFA register, which means that we may need to generate a new pattern for use by the unwind info. */ And this is a sample of pre- and post-patch in pro_and_epilogue: RTL pre-patch: (insn/f 41 40 42 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 6 bp) (const_int -160 [0xffffffffffffff60])) [6 S16 A64]) (reg:V4SF 27 xmm6)) "/c/Users/daniel/proj/sys/gcc/github/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5b.c":29 -1 (nil)) RTL post-patch: (insn/f 41 40 42 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp) (const_int 48 [0x30])) [6 S16 A128]) (reg:V4SF 27 xmm6)) "/c/Users/daniel/proj/sys/gcc/github/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5b.c":29 -1 (expr_list:REG_CFA_EXPRESSION (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp) (const_int 48 [0x30])) [6 S16 A128]) (reg:V4SF 27 xmm6)) (nil))) I haven't learned much of the dwarf code so I can't fully appreciate the function of all of these notes, but if we're using the SP should I just omit the note and let dwarf intuit the insn? The test in i386_pe_seh_unwind_emit() presumes that if we're using REG_CFA_EXPRESSION then we've used DRAP, but that isn't the case after this patch. Can you please advise on the correct solution? My current guess is to just remove the above chunk (or at least remove the note). Also of note, I need to do more analysis on why my tests did not expose this flaw, since va args is something that it tests. Thanks! Daniel