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

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

[jsm28 at gcc dot gnu dot org]

The following test wrongly fails with a floating point exception (division
by integer 0) when built with -O2 for i686-pc-linux-gnu.  Based on an
example posted by Robert Seacord to the WG14 reflector.  It works with 3.4 and
earlier, fails with 4.0 and later.  The % operation may trap if it is % 0
(or INT_MIN % -1, cf bug 30484 and another recent reflector discussion
suggesting INT_MIN % -1 should in fact be undefined in ISO C), so cannot be
hoisted above the loop unless it is guaranteed to be executed at least once.

extern void exit (int);
extern void abort (void);

volatile int a = 1;
volatile int b = 0;
volatile int x = 2;
volatile signed int r = 8;

void __attribute__((noinline))
foo (void)
{
  exit (0);
}

int
main (void)
{
  int si1 = a;
  int si2 = b;
  int i;

  for (i = 0; i < 100; ++i) {
    foo ();
    if (x == 8)
      i++;
    r += i + si1 % si2;
  }
  abort ();
}


-- 
           Summary: [4.2/4.3/4.4 Regression] trapping expression wrongly
                    hoisted out of loop
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jsm28 at gcc dot gnu dot org


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-01-13 09:51 -------
It should be ok with -fnon-call-exceptions.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|---                         |4.2.5


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2009-01-15 16:00 -------
Maybe not really P1, but we certainly should investigate why tree-ssa broke
this.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.0.0
      Known to work|                            |3.4.6
           Priority|P3                          |P1
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-15 16:00:58
               date|                            |


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

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

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2009-01-16 11:21 -------
-O2 -fno-tree-pre works.  tree_could_trap_p is true for integer division by
non-constant (or 0), but we don't seem to have stmt_could_trap_p.  Perhaps it
should be added and PRE should considfer it?  In rtl land, may_trap_p is also
true in this case and so RTL optimizers don't try to hoist this out of loops.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2009-01-16 11:41 -------
Optimal would be to check this at insertion time, a quick fix is to adjust
compute_avail to not consider trapping expressions.

Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-01-15 16:00:58         |2009-01-16 11:41:40
               date|                            |


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

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

[rguenth at gcc dot gnu dot org]

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

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

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-01-16 20:24 -------
int
main (void)
{
  int si1 = a;
  int si2 = b;
  int i;

  for (i = 0; i < 100; ++i) {
    if (a == 2)
      exit (0);
    r += si1 % si2;
  }
  abort ();
}

shows that PRE doesn't move code to where it executes more times than before
the transformation.  If it knows about this extra control-flow.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2009-01-16 20:44 -------
Hmm, maybe we need to what exactly is done for profiling and split the basic
blocks at the function call boundaries but that would definitely cause lots of
compile time regressions.


-- 


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

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

[dberlin at dberlin dot org]

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

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

[rguenther at suse dot de]

------- Comment #9 from rguenther at suse dot de  2009-01-16 21:01 -------
Subject: Re:  [4.2/4.3/4.4 Regression] trapping
 expression wrongly hoisted out of loop

On Fri, 16 Jan 2009, dberlin at dberlin dot org wrote:

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

Like all loads from pointers? :/

I'll try to do something slightly more clever.

Richard.


-- 


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

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

[dberlin at dberlin dot org]

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

On Fri, Jan 16, 2009 at 4:01 PM, rguenther at suse dot de
<gcc-bugzilla@gcc.gnu.org> wrote:
>
>
> ------- Comment #9 from rguenther at suse dot de  2009-01-16 21:01 -------
> Subject: Re:  [4.2/4.3/4.4 Regression] trapping
>  expression wrongly hoisted out of loop
>
> On Fri, 16 Jan 2009, dberlin at dberlin dot org wrote:
>
>> 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.
>
> Like all loads from pointers? :/
>
> I'll try to do something slightly more clever.

Ugh.
What do other compilers do here?
Honestly, if they are just as broken as us, i say we just do nothing.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-16 22:24 -------
Created an attachment (id=17124)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17124&action=view)
patch

Patch I am testing.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2009-01-16 22:26 -------
A different possible patch would be to have a special mode that pre-splits
the CFG at the possible exit points and insert edges to the exit BB.  We
could condition that on a flag or so.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2009-01-16 22:51 -------
Btw, I am sure this is not a problem for loads, as only CFG exits from
functions
causes the bogus PRE and that always clobbers memory if it may call exit
(pure and const functions may not).  It may become a problem in future, but not
now.

In future we may want to have an IPA pass computing wheter a function may
possibly not return and use this information to pre-split BBs and insert
exit edges before PRE as a better general solution.  Maybe this is what
other compilers do (the Intel compiler doesn't PRE the modulo in this
testcase).


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2009-01-18 15:49 -------
Fixed for GCC 4.4, lowering priority.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|3.4.6                       |3.4.6 4.4.0
           Priority|P1                          |P2
            Summary|[4.2/4.3/4.4 Regression]    |[4.2/4.3 Regression]
                   |trapping expression wrongly |trapping expression wrongly
                   |hoisted out of loop         |hoisted out of loop


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2009-01-18 15:51 -------
Subject: Bug 38819

Author: rguenth
Date: Sun Jan 18 15:51:12 2009
New Revision: 143485

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143485
Log:
2009-01-18  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/38819
        * tree-flow.h (operation_could_trap_helper_p): Declare.
        * tree-eh.c (operation_could_trap_helper_p): Export.
        * tree-ssa-sccvn.h (vn_nary_may_trap): Declare.
        * tree-ssa-sccvn.c (vn_nary_may_trap): New function.
        * tree-ssa-pre.c (insert_into_preds_of_block): Check if we
        are about to insert a possibly trapping instruction and fail
        in this case.

        * gcc.c-torture/execute/pr38819.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr38819.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-eh.c
    trunk/gcc/tree-flow.h
    trunk/gcc/tree-ssa-pre.c
    trunk/gcc/tree-ssa-sccvn.c
    trunk/gcc/tree-ssa-sccvn.h


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #16 from ebotcazou at gcc dot gnu dot org  2009-02-08 17:59 -------
Still present on SPARC 32-bit on the mainline:

FAIL: gcc.c-torture/execute/pr38819.c execution,  -O2 
FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer
-funroll-loops 
FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/pr38819.c execution,  -O3 -g

The culprit is RTL PRE GCSE.


-- 


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

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

[jsm28 at gcc dot gnu dot org]

------- Comment #17 from jsm28 at gcc dot gnu dot org  2009-03-31 21:07 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3 Regression]        |[4.3 Regression] trapping
                   |trapping expression wrongly |expression wrongly hoisted
                   |hoisted out of loop         |out of loop
   Target Milestone|4.2.5                       |4.3.4


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2009-08-04 12:29 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

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

[davem at gcc dot gnu dot org]

------- Comment #19 from davem at gcc dot gnu dot org  2010-03-12 21:00 -------
Like Eric I'm still seeing this fail on mainline on 32-bit sparc.


-- 


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

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #20 from ebotcazou at gcc dot gnu dot org  2010-03-12 21:27 -------
> Like Eric I'm still seeing this fail on mainline on 32-bit sparc.

The problem is that this is hard to fix without pessimizing the common case.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-03-13 11:03 -------
(In reply to comment #20)
> > Like Eric I'm still seeing this fail on mainline on 32-bit sparc.
> 
> The problem is that this is hard to fix without pessimizing the common case.

The rtl gcse pre issue should be tracked by a different bugzilla report.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2010-05-22 18:13 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


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

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

[ubizjak at gmail dot com]

------- Comment #23 from ubizjak at gmail dot com  2010-08-07 08:26 -------
(In reply to comment #21)

> > The problem is that this is hard to fix without pessimizing the common case.
> 
> The rtl gcse pre issue should be tracked by a different bugzilla report.

Follow up at PR45223.


-- 


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