https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #1 from Andrew Pinski ---
I think it comes down to the same issue as PR 18501.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #2 from Linus Torvalds ---
(In reply to Andrew Pinski from comment #1)
> I think it comes down to the same issue as PR 18501.
Very possibly the same issue in just a different guise.
NOTE! I have in the meantime verified that yes, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #3 from Jeffrey A. Law ---
Yup. It's the same as 18501. We meet UNDEFINED and [0,0] resulting in [0,0]
and nothing ever causes reevaluation of the PHI. Things are working as
"expected".
My approach from 2005 would almost certa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #5 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #3)
> Yup. It's the same as 18501. We meet UNDEFINED and [0,0] resulting in
> [0,0] and nothing ever causes reevaluation of the PHI. Things are working
> as "expec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #6 from Linus Torvalds ---
(In reply to Richard Biener from comment #5)
>
> And this meeting helps us avoid bogus warnings for cases where GCC has
> difficulties proving dead code paths are actually dead ...
Ack. I do see the diffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #7 from Jeffrey A. Law ---
It's reliably the case that a false positive uninit warning also represents a
failure to optimize something. So we've got significant incentives to deeply
analyze and look for fixes. So feel free to pass e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #8 from Linus Torvalds ---
(In reply to Jeffrey A. Law from comment #7)
> It's reliably the case that a false positive uninit warning also represents
> a failure to optimize something. So we've got significant incentives to
> deeply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
ncm at cantrip dot org changed:
What|Removed |Added
CC||ncm at cantrip dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #10 from Linus Torvalds ---
(In reply to ncm from comment #9)
> What I don't understand is why it doesn't optimize away the check on
> (somecondition), since it is assuming the code in the dependent block always
> runs.
No, it very m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #11 from Jeffrey A. Law ---
WRT c#9. Linus is right. THe condition is dynamic and we don't want to remove
it in this circumstance.
More generally we have considered whether or not we could eliminate the
control dependent path whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #12 from Linus Torvalds ---
(In reply to Jeffrey A. Law from comment #11)
>
> More generally we have considered whether or not we could eliminate the
> control dependent path which leads to undefined behavior. But you have to
> be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #13 from ncm at cantrip dot org ---
What I am getting is that the compiler is leaving that permitted optimization
-- eliminating the inode check -- on the table. It is doing that not so much
because it would make Linus angry, but as an
13 matches
Mail list logo
