[Bug tree-optimization/103079] [12 Regression] wrong code at -Os and -O2 on x86_64-linux-gnu (the generated code hangs) since r12-4871-g502ffb1f389011b2

amacleod at redhat dot com gcc-bugzilla@gcc.gnu.org
Thu Nov 4 13:37:19 GMT 2021


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 51735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51735&action=edit
patch for the undefined bit

(In reply to Richard Biener from comment #7)
> =========== BB 2 ============
> Imports: b.0_1  t_4(D)
> Exports: b.0_1  t_4(D)  _6
>          _6 : b.0_1(I)  t_4(D)(I)
> t_4(D)  UNDEFINED
>     <bb 2> [local count: 176285970]:
>     b.0_1 = b;
>     _6 = b.0_1 | t_4(D);
>     if (_6 != 0)
>       goto <bb 3>; [34.00%]
>     else
>       goto <bb 7>; [66.00%]
> 
> 2->3  (T) b.0_1 :       UNDEFINED
> 2->3  (T) t_4(D) :      UNDEFINED
> 2->3  (T) _6 :  int [-INF, -1][1, +INF]
> 
> I think 2->3 (T) b.0_1 : UNDEFINED is wrong.  if b.0_1 is 1 then 1 | UNDEF
> is still 1 and there's nothing "undefined" in evaluating if (1 | UNDEF !+ 0).

yeah looks like gori calculations just assumes an undefined argument makes
everything undefined..  we should probably just left the op1/op2_range routines
handle it.
We can't actually know b.0_1 if the branch is taken because of the undefined,
so it'll get calculated as varying. With the untested patch, we now get

2->3  (T) t_4(D) :      UNDEFINED
2->3  (T) _6 :  int [-INF, -1][1, +INF]
2->7  (F) b.0_1 :       int [0, 0]
2->7  (F) t_4(D) :      UNDEFINED
2->7  (F) _6 :  int [0, 0] 

we do know that b.0_1 is 0 on the false side...


More information about the Gcc-bugs mailing list