From patchwork Tue Nov 24 07:32:07 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aurelien Jarno X-Patchwork-Id: 9800 Received: (qmail 80644 invoked by alias); 24 Nov 2015 07:32:16 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 80632 invoked by uid 89); 24 Nov 2015 07:32:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.2 required=5.0 tests=BAYES_50, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: hall.aurel32.net Date: Tue, 24 Nov 2015 08:32:07 +0100 From: Aurelien Jarno To: Florian Weimer Cc: Allan McRae , libc-alpha Subject: Re: nptl/tst-cleanupx4 fails with gcc-4.9.0 on i686 Message-ID: <20151124073207.GA29465@aurel32.net> Mail-Followup-To: Florian Weimer , Allan McRae , libc-alpha References: <53579447.20309@archlinux.org> <20140617125947.GC13498@hall.aurel32.net> <554872A2.3010601@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <554872A2.3010601@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) On 2015-05-05 09:34, Florian Weimer wrote: > On 06/17/2014 02:59 PM, Aurelien Jarno wrote: > > > So I do wonder what we should do on i386: > > > > (a) Ignore the test on i386 similarly to ARM. > > > > (b) Create tst-cleanupx4aux.c, which includes tst-cleanup4aux.c but is > > built using -fexceptions, and use it to link with tst-cleanupx4. > > > > Any opinion? > > Do we know actually what causes the failure? Why isn't this a real bug? I have been able to determine the regression is caused by the following patch on the gcc side: commit d3536cda416e946adbe38d2f71fce378c6f17b63 Author: hubicka Date: Thu Oct 3 17:25:42 2013 +0000 * i386.c (ix86_option_override_internal): Do not enable accumulate-outgoing-args when producing unwind info. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@203171 138bc75d-0d04-0410-961f-82ee72b054a4 diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 138d6c5..93cd63d 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2013-10-03 Jan Hubicka + + * i386.c (ix86_option_override_internal): Do not enable + accumulate-outgoing-args when producing unwind info. + 2013-10-03 Wei Mi * lra-constraints.c (insert_move_for_subreg): New function diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 21fc531..09b0fc5 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -3793,28 +3793,11 @@ ix86_option_override_internal (bool main_args_p) } ix86_tune_mask = 1u << ix86_tune; - if ((!USE_IX86_FRAME_POINTER - || (x86_accumulate_outgoing_args & ix86_tune_mask)) + if ((x86_accumulate_outgoing_args & ix86_tune_mask) && !(target_flags_explicit & MASK_ACCUMULATE_OUTGOING_ARGS) && !optimize_size) target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS; - /* ??? Unwind info is not correct around the CFG unless either a frame - pointer is present or M_A_O_A is set. Fixing this requires rewriting - unwind info generation to be aware of the CFG and propagating states - around edges. */ - if ((flag_unwind_tables || flag_asynchronous_unwind_tables - || flag_exceptions || flag_non_call_exceptions) - && flag_omit_frame_pointer - && !(target_flags & MASK_ACCUMULATE_OUTGOING_ARGS)) - { - if (target_flags_explicit & MASK_ACCUMULATE_OUTGOING_ARGS) - warning (0, "unwind tables currently require either a frame pointer " - "or %saccumulate-outgoing-args%s for correctness", - prefix, suffix); - target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS; - } - /* If stack probes are required, the space used for large function arguments on the stack must also be probed, so enable -maccumulate-outgoing-args so this happens in the prologue. */