[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