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


             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: link
Be 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).