From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10787 invoked by alias); 15 Jun 2010 11:37:14 -0000 Received: (qmail 10730 invoked by uid 48); 15 Jun 2010 11:36:58 -0000 Date: Tue, 15 Jun 2010 11:37:00 -0000 Message-ID: <20100615113658.10729.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value 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: 2010-06/txt/msg01591.txt.bz2 ------- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 11:36 ------- I don't have any wrong-code testcases. __attribute__((noinline, noclone)) void f (long x) { long a, b, c, d; asm (""); __builtin_alloca (1); } int main (void) { f (1234567890); return 0; } shows the same issue at -O0 -g as I see on redhat/gcc-4_4-branch on the trunk between r145138 (which I've backported to 4.4-RH, perhaps I'll need to back it out) and r146817 (SSA expand). In between those two commits the trunk first sets DECL_ALIGN to 256 bits on one of the variables (as offset 32 gives and is still smaller or equal to MAX_SUPPORTED_STACK_ALIGNMENT) and then expand_stack_var is called on it again and bumps crtl->stack_alignment_estimated to 256 (something that isn't really needed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542