From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9753 invoked by alias); 9 Jul 2009 13:58:09 -0000 Received: (qmail 9629 invoked by uid 48); 9 Jul 2009 13:57:48 -0000 Date: Thu, 09 Jul 2009 13:58:00 -0000 Message-ID: <20090709135748.9628.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: "hjl dot tools at gmail dot com" 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/msg00770.txt.bz2 ------- Comment #9 from hjl dot tools at gmail dot com 2009-07-09 13:57 ------- (In reply to comment #8) > 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. You may have an unaligned parameter. If it is spilled onto stack, stack should be properly aligned. It isn't a problem for DImode. But it may be a problem for other types. There may be some testcases aleady to test it. If not, I can add a few. What happened is we find DImode and try to align stack. At the last minute, we find it isn't spilled and we skip the stack alignment. What we need it is MINIMUM_TYPE_ALIGN, which is the minimum alignment for a type. MINIMUM_TYPE_ALIGN should be the same as TYPE_ALIGN. But on IA32, MINIMUM_TYPE_ALIGN (DImode) == 4 and TYPE_ALIGN (DImode) == 8. We can use MINIMUM_TYPE_ALIGN for stack alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40667