From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17627 invoked by alias); 3 Mar 2010 16:56:28 -0000 Received: (qmail 17430 invoked by uid 48); 3 Mar 2010 16:56:10 -0000 Date: Wed, 03 Mar 2010 16:56:00 -0000 Message-ID: <20100303165610.17429.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/42313] FAIL: gcc.target/i386/builtin-unreachable.c scan-assembler-not %e[bs]p on i686 darwin In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikestump at comcast dot net" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00299.txt.bz2 ------- Comment #7 from mikestump at comcast dot net 2010-03-03 16:56 ------- I fixed the test case to not expect the unimplemented optimization in r157197, however, it would be nice to ensure the async signal handlers can handle unaligned stacks and to perform this optimization. I'm fairly certain the signal handers have to cope as code gen can do: _h: subl $12, %esp movl $1, %eax addl $12, %esp ret for int h () { return 1; } and certainly we can take a signal at _h+0, where esp isn't aligned. Given that, we can omit sp alignments for leaf functions (and no tail calls either), even on machines where otherwise an alignment is required, as long as any variables on the stack are correctly aligned. When this optimization is added, we can undo the r157197 change. -- mikestump at comcast dot net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikestump at comcast dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42313