public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
Date: Thu, 14 Jun 2007 17:58:00 -0000	[thread overview]
Message-ID: <20070614175801.28867.qmail@sourceware.org> (raw)
In-Reply-To: <bug-32327-91@http.gcc.gnu.org/bugzilla/>



------- Comment #19 from ian at airs dot com  2007-06-14 17:57 -------
Adding Richard in case he has any comment.

I don't agree with comment #17 from Doug.  In the code in comment #16, if f
saves &c, there is no way that it could validly use it after the block scope
exits.

In general if we expand the scope of a variable outside of its block scope,
then the stack sharing code in cfgexpand.c will do the wrong thing.  There is
normally no reason for the tree code to expand the scope of a variable.  But
there is also nothing specifically to stop it from doing so.

In this particular case store sinking is extending the life of a variable. 
This is a meaningless move, as there is no valid way for the stored value to be
accessed.  It is happening because alias analysis thinks that the function call
can refer to the stored variable, although this actually can not happen.

Part of the reason alias analysis is wrong is that we retain the list of
addressable variables in a statement when we shouldn't.  Interestingly, if I
apply the tree-ssa-operands.c patch from
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01807.html then the problem goes
away.

But there are a few complex issues here:

1) Alias analysis thinks that a function can refer to a variable in a different
block scope.

2) Nothing systematically prevents the tree code from referencing or setting
variables outside of their block scope.

3) The stack sharing code in cfgexpand assumes that variables are only
referenced or set within their block scope.

This is going to require more investigation.  I think we are mainly lucky
because the tree optimizers tend to not move variables outside of their block
scope.  This test case just happens to show a way in which that can happen.


-- 

ian at airs dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org,
                   |                            |ian at airs dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327


  parent reply	other threads:[~2007-06-14 17:58 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-13 19:57 [Bug c/32327] New: " dnovillo at gcc dot gnu dot org
2007-06-13 21:20 ` [Bug middle-end/32327] " pinskia at gcc dot gnu dot org
2007-06-13 21:25 ` dougkwan at google dot com
2007-06-13 21:32 ` pinskia at gcc dot gnu dot org
2007-06-13 21:37 ` pinskia at gcc dot gnu dot org
2007-06-13 21:42 ` [Bug middle-end/32327] [4.2 Regression] " pinskia at gcc dot gnu dot org
2007-06-13 21:50 ` dougkwan at google dot com
2007-06-13 21:53 ` pinskia at gcc dot gnu dot org
2007-06-14  0:14 ` dougkwan at google dot com
2007-06-14  0:28 ` pinskia at gcc dot gnu dot org
2007-06-14  0:35 ` dougkwan at google dot com
2007-06-14  0:42 ` pinskia at gcc dot gnu dot org
2007-06-14  0:42 ` pinskia at gcc dot gnu dot org
2007-06-14  0:46 ` dougkwan at google dot com
2007-06-14  0:52 ` pinskia at gmail dot com
2007-06-14  0:59 ` dougkwan at google dot com
2007-06-14  1:02 ` pinskia at gcc dot gnu dot org
2007-06-14  1:09 ` dougkwan at google dot com
2007-06-14  1:14 ` pinskia at gmail dot com
2007-06-14 17:58 ` ian at airs dot com [this message]
2007-06-14 18:05 ` dougkwan at google dot com
2007-06-14 18:13 ` rguenther at suse dot de
2007-06-15 13:15 ` mec at google dot com
2007-06-15 13:27 ` dnovillo at gcc dot gnu dot org
2007-06-15 22:10 ` dnovillo at gcc dot gnu dot org
2007-06-18 12:31 ` dnovillo at gcc dot gnu dot org
2007-06-19 17:26 ` rth at gcc dot gnu dot org
2007-06-19 17:40 ` dnovillo at google dot com
2007-06-19 18:58 ` amacleod at redhat dot com
2007-07-04  3:29 ` mmitchel at gcc dot gnu dot org
2007-07-04 11:23 ` dnovillo at google dot com
2007-07-20  3:46 ` mmitchel at gcc dot gnu dot org
2007-10-09 19:22 ` mmitchel at gcc dot gnu dot org
2008-02-01 16:58 ` jsm28 at gcc dot gnu dot org
2008-05-19 20:27 ` jsm28 at gcc dot gnu dot org
2009-03-30 22:06 ` jsm28 at gcc dot gnu dot org

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=20070614175801.28867.qmail@sourceware.org \
    --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).