https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2018-07-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #6 from rguenther at suse dot de ---
On Mon, 23 Jul 2018, glisse at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
>
> --- Comment #5 from Marc Glisse ---
> (In reply to Richard Biener from comment #4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #5 from Marc Glisse ---
(In reply to Richard Biener from comment #4)
> Yeah, generally we can't associate because (x*y)*z may not overflow because
> x == 0 but x*(y*z) may because y*z overflows.
We can do it
- in the wrapping case (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #3 from Marc Glisse ---
We already simplify some simple cases like x*t/t -> x in match.pd. Larger cases
are for a pass like reassoc. In this particular case, we could also imagine
somehow noticing that (x*y)*z is better reassociated a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
--- Comment #2 from Dávid Bolvanský ---
Something/0 is undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86628
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|c
