https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783
--- Comment #5 from Andrew Pinski ---
The problem with the conversion that is suggested here is the addition if
changed into a signed type might have an undefined behavior when it comes to an
overflow.
It does not matter if it is used later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07
18:25:19 UTC ---
I think that would be an invalid transformation except when -fwrapv is used.
The reason is:
x.0_2 = (unsigned int) x_1(D);
D.2715_4 = z_3(D) + x.0_2;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783
--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-01-07 18:55:05
UTC ---
Well, IMHO it is still valid in the case of argument of ne/eq comparison, as
indeed here sign and wrap-around doesn't matter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-07
18:57:52 UTC ---
(In reply to comment #2)
Well, IMHO it is still valid in the case of argument of ne/eq comparison, as
indeed here sign and wrap-around doesn't matter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51783
--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-01-07 19:04:13
UTC ---
Hmm, here I disagree. See other ==/!= comparison missed optimization.
Eg for 'x == (signed type)((unsigned type) x + z)' the transformation is
profitable, as it
