https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #11 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:004afb984beb6efbe25f44a5857b1c27ebc2ec82
commit r12-4921-g004afb984beb6efbe25f44a5857b1c27ebc2ec82
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #10 from Andrew Macleod ---
That patch wont generally work until rangeops op1_range routines are adjusted
to deal with undefined being passed in.. I think it assumes until now that its
been trimmed out.
(In reply to Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #9 from Andrew Macleod ---
Created attachment 51735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51735=edit
patch for the undefined bit
(In reply to Richard Biener from comment #7)
> === BB 2
> Imports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #8 from Richard Biener ---
Btw, I find the vrp-details dump not really useful with all the ranger
"debug" appearing _after_ the folding of stmts. Can we instead have
this somehow interleaved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #7 from Richard Biener ---
=== 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
[local count: 176285970]:
b.0_1 = b;
_6 = b.0_1 | t_4(D);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #6 from Andrew Pinski ---
VRP2:
Predicate evaluates to: DON'T KNOW
Matching expression match.pd:1972, gimple-match.c:819
Matching expression match.pd:1975, gimple-match.c:892
Matching expression match.pd:1982, gimple-match.c:952
Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #5 from Martin Liška ---
> static int c() {
> if (b)
> return b;
> }
Yes, one can use the return value as long as the function returns a value.
This means, c() can be used iff b != 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> The problem is latent though. The issue is reassociatation introduces an
> unconditional use of an uninitilized vairable:
Whoops that is not the issue here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
--- Comment #3 from Andrew Pinski ---
The problem is latent though. The issue is reassociatation introduces an
unconditional use of an uninitilized vairable:
Before
if (b.1_3 != 0)
goto ; [34.00%]
else
goto ; [66.00%]
[local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
Martin Liška changed:
What|Removed |Added
Keywords||wrong-code
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103079
Martin Liška changed:
What|Removed |Added
Summary|wrong code at -Os and -O2 |[12 Regression] wrong code
12 matches
Mail list logo
