From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24219 invoked by alias); 9 Jul 2009 13:25:38 -0000 Received: (qmail 23809 invoked by uid 48); 9 Jul 2009 13:25:20 -0000 Date: Thu, 09 Jul 2009 13:25:00 -0000 Message-ID: <20090709132520.23808.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" 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: 2009-07/txt/msg00767.txt.bz2 ------- Comment #8 from jakub at gcc dot gnu dot org 2009-07-09 13:25 ------- Created an attachment (id=18170) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18170&action=view) gcc45-pr40667.patch Very ugly patch which just shows that changing these 3 spots helps both of these testcases. It uses minimum of the currently used alignment and LOCAL_ALIGNMENT/LOCAL_DECL_ALIGNMENT/STACK_SLOT_ALIGNMENT, so only when these functions return smaller alignment than expected they change anything. As only i386/x86_64 is SUPPORTS_STACK_ALIGNMENT supporting platform and only for DImode on -m32 we ever decrease the stack alignment, this shouldn't break anything. BTW, the patch also changes something that looks like a thinko to me: unsigned int align = FUNCTION_ARG_BOUNDARY (data.promoted_mode, data.passed_type); if (TYPE_ALIGN (data.nominal_type) > align) align = TYPE_ALIGN (data.passed_type); data.passed_type has already been used in FUNCTION_BOUNDARY computation, so it really surprises me it doesn't use nominal_type's TYPE_ALIGN instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667