This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/38819] [4.2/4.3/4.4 Regression] trapping expression wrongly hoisted out of loop



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]