https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #23 from Richard Biener ---
This should fix the missed CSE Andrew noticed, not sure if it is enough to
aovid the bogus diagnostic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #22 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:fe8475c500939011b90504304aec61bf6f48ac7d
commit r12-4625-gfe8475c500939011b90504304aec61bf6f48ac7d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #21 from Richard Biener ---
(In reply to Andrew Pinski from comment #14)
> Created attachment 51650 [details]
> Little more reduced
>
> So FRE is able to figure out for the following:
> # _20 = PHI <0(2), 1(3)>
> # const_upper_2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #20 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.
>
> FAIL: path through PHI in b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #19 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.
>
> FAIL: path through PHI in b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #18 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #9)
> So in uninit1 we have:
> if (_6691 != 0)
> goto ; [5.50%]
> else
> goto ; [94.50%]
>
>[local count: 17344687]:
> goto ; [100.00%]
>
>[l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Tamar Christina changed:
What|Removed |Added
CC|tamar.christina at arm dot com |
--- Comment #17 from Tamar Ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #16 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #15)
> We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.
FAIL: path through PHI in bb8 (incoming bb:6) crosses loop
But but, it does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #15 from Andrew Pinski ---
So the major difference comes from mark_stack_region_used.
We have a missing jump thread in ethread.
Before the patch, ethread was able to jump thread all the way through:
if (_13 != 0)
goto ; [5.50%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Andrew Pinski changed:
What|Removed |Added
Attachment #51649|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Andrew Pinski changed:
What|Removed |Added
Attachment #51648|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #12 from Andrew Pinski ---
So this is definitely a bad interaction between complete unrolling where we
had:
for (unsigned int i = 1; i < 2; i++)
if (this->coeffs[1] != 0)
return false;
And jump threading.
I am still redu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #11 from Andrew Pinski ---
Good news I can reproduce the warning with the preprocessed source on a native
x86_64-linux-gnu trunk GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #10 from Andrew Pinski ---
Hmm, somehow unroll messes up the relationship ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #9 from Andrew Pinski ---
So in uninit1 we have:
if (_6691 != 0)
goto ; [5.50%]
else
goto ; [94.50%]
[local count: 17344687]:
goto ; [100.00%]
[local count: 298013267]:
[local count: 315357954]:
# const_up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #8 from Andrew Pinski ---
Created attachment 51648
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51648&action=edit
preprocessed source
unreduced preprocessed source which fails still as of r12-4600.
-fno-PIE -c -g -O2 -fno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #7 from Andrew Pinski ---
This still fails as of r12-4600-gf5ef4da3ccdfbedb .
I will go debug this tomorrow to see what exactly is going on and why the
warning is still not resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #4 from Feng Xue ---
(In reply to Martin Sebor from comment #3)
> Simply initializing the variable as in the patch below avoids the warning.
> The control flow in the code is sufficiently opaque to make it worthwhile
> from a readab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #3 from Martin Sebor ---
Simply initializing the variable as in the patch below avoids the warning. The
control flow in the code is sufficiently opaque to make it worthwhile from a
readability point irrespective of whether or not th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |bootstrap
Summary|AArch64 b
23 matches
Mail list logo
