public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/44542] New: expand_one_stack_var_at may set DECL_ALIGN to a too high value Date: Tue, 15 Jun 2010 10:51:00 -0000 [thread overview] Message-ID: <bug-44542-87@http.gcc.gnu.org/bugzilla/> (raw) 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
next reply other threads:[~2010-06-15 10:51 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-06-15 10:51 jakub at gcc dot gnu dot org [this message] 2010-06-15 11:19 ` [Bug target/44542] " matz at gcc dot gnu dot org 2010-06-15 11:37 ` jakub at gcc dot gnu dot org 2010-06-15 12:53 ` jakub at gcc dot gnu dot org 2010-06-15 13:41 ` matz at gcc dot gnu dot org 2010-06-15 13:51 ` matz at gcc dot gnu dot org 2010-06-15 14:47 ` hjl dot tools at gmail dot com 2010-06-15 14:56 ` matz at gcc dot gnu dot org 2010-06-15 15:39 ` hjl dot tools at gmail dot com 2010-06-15 16:46 ` jakub at gcc dot gnu dot org 2010-06-15 17:13 ` hjl dot tools at gmail dot com 2010-06-15 17:20 ` hjl dot tools at gmail dot com 2010-06-15 17:25 ` hjl dot tools at gmail dot com 2010-06-16 6:56 ` jakub at gcc dot gnu dot org 2010-06-16 14:36 ` hjl dot tools at gmail dot com 2010-06-16 14:58 ` jakub at gcc dot gnu dot org 2010-06-16 15:38 ` hjl dot tools at gmail dot com 2010-07-27 17:55 ` jakub at gcc dot gnu dot org 2010-07-27 18:00 ` jakub at gcc dot gnu dot org 2010-09-17 20:25 ` hjl dot tools at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-44542-87@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).