From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4996 invoked by alias); 15 Jun 2010 10:51:55 -0000 Received: (qmail 4930 invoked by uid 48); 15 Jun 2010 10:51:38 -0000 Date: Tue, 15 Jun 2010 10:51:00 -0000 Subject: [Bug target/44542] New: expand_one_stack_var_at may set DECL_ALIGN to a too high value X-Bugzilla-Reason: CC Message-ID: 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/msg01588.txt.bz2 On say -O0: void foo (long x) { long a, b, c, d; __builtin_alloca (1); } some of the variables get much higher DECL_ALIGN than they in the end really have. I don't have a testcase which shows miscompilation on the trunk, still it seems to be a latent bug. IMHO it should instead set DECL_ALIGN to the maximum of requested DECL_ALIGN and alignment from offset for minimum possible stack alignment and only after expansion when it is finalized what stack alignment it will have it can be increased if needed. On 4.4-RH I've run into another issue (perhaps also latent on the trunk) - if expand_stack_var is called twice on the same variable, the first time it is given a stack slot and DECL_ALIGN set to a very high number (e.g. for offset 32 it is 256 bits) and next time the function doesn't do almost anything (DECL_RTL_SET_P is true), except for increasing requested alignment to the given one, so it ends up wanting to realign the stack. -- Summary: expand_one_stack_var_at may set DECL_ALIGN to a too high value Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542