From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-273045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30788 invoked by alias); 16 Jan 2009 20:48:54 -0000
Received: (qmail 30756 invoked by alias); 16 Jan 2009 20:48:44 -0000
Date: Fri, 16 Jan 2009 20:48:00 -0000
Message-ID: <20090116204844.30755.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-38819-230@http.gcc.gnu.org/bugzilla/>
Subject: [Bug tree-optimization/38819] [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop
In-Reply-To: <bug-38819-230@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "dberlin at dberlin dot org" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2009-01/txt/msg01847.txt.bz2



------- Comment #8 from dberlin at gcc dot gnu dot org  2009-01-16 20:48 -------
Subject: Re:  [4.2/4.3/4.4 Regression] trapping 
        expression wrongly hoisted out of loop

Hmmm.
The only way you could get the CFG to represent that any call may exit
would be to calls terminate bb's and have an edge from every call to
exit.
:(

We actually do this with noreturn edges.
It's probably a lot easier to just not move trapping expressions for now.



On Fri, Jan 16, 2009 at 3:04 PM, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #5 from rguenth at gcc dot gnu dot org  2009-01-16 20:04 -------
> PRE shouldn't cause new evaluations - the issue here is that the CFG
>
>  # BLOCK 2 freq:900
>  # PRED: ENTRY [100.0%]  (fallthru,exec)
>  si1_3 ={v} a;
>  si2_4 ={v} b;
>  # SUCC: 3 [100.0%]  (fallthru,exec)
>
>  # BLOCK 3 freq:9100
>  # PRED: 8 [100.0%]  (fallthru) 2 [100.0%]  (fallthru,exec)
>  # i_31 = PHI <i_12(8), 0(2)>
>  foo ();
>  x.0_6 ={v} x;
>  if (x.0_6 == 8)
>    goto <bb 4>;
>  else
>    goto <bb 7>;
>  # SUCC: 4 [28.0%]  (true,exec) 7 [72.0%]  (false,exec)
>
>
>  # BLOCK 7 freq:6552
>  # PRED: 3 [72.0%]  (false,exec)
>  goto <bb 5>;
>  # SUCC: 5 [100.0%]  (fallthru)
>
>  # BLOCK 4 freq:2548
>  # PRED: 3 [28.0%]  (true,exec)
>  i_7 = i_31 + 1;
>  # SUCC: 5 [100.0%]  (fallthru,exec)
>
>  # BLOCK 5 freq:9100
>  # PRED: 7 [100.0%]  (fallthru) 4 [100.0%]  (fallthru,exec)
>  # i_1 = PHI <i_31(7), i_7(4)>
>  D.1253_8 = si1_3 % si2_4;
>  r.1_10 ={v} r;
>  D.1254_9 = D.1253_8 + r.1_10;
>  r.2_11 = D.1254_9 + i_1;
>  r ={v} r.2_11;
>  i_12 = i_1 + 1;
>  if (i_12 <= 99)
>    goto <bb 8>;
>  else
>    goto <bb 6>;
>  # SUCC: 8 [90.1%]  (true,exec) 6 [9.9%]  (false,exec)
>
>  # BLOCK 8 freq:8200
>  # PRED: 5 [90.1%]  (true,exec)
>  goto <bb 3>;
>  # SUCC: 3 [100.0%]  (fallthru)
>
>  # BLOCK 6 freq:900
>  # PRED: 5 [9.9%]  (false,exec)
>  abort ();
>  # SUCC:
>
> does not model the fact that foo () does not return.
>
> Danny, do you have any suggestion (besides to try to avoid trapping stuff
> somehow) to model this?
>
>
> --
>
> rguenth at gcc dot gnu dot org changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |dberlin at gcc dot gnu dot
>                   |                            |org
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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