This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/30245] -O2 generates bad code
- From: "pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 18 Dec 2006 09:59:40 -0000
- Subject: [Bug c++/30245] -O2 generates bad code
- References: <bug-30245-9596@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-18 09:59 -------
(In reply to comment #3)
> (In reply to comment #1)
> > then it can only be postive
>
> Plausible, but I don't think so.
Again signed type overflow is undefined by the C standard so it can do
anything.
So in this case, we optimize out the n == 0 compare.
>
> The executed code displays a negative number after about
> 64 iterations, then displays about thirty zeros.
>
> There is one set bit in local variable n, and it gets moved up
> once per iteration.
>
> At the last but one iteration, n goes negative, because
> the sign bit is set.
Again once you have a signed overflow, then the behavior is undefined which is
why the n == 0 compare is optimized to true.
>
> Then n goes to zero.
>
> Then the test for n == 0 mysteriously fails in the optimiser.
Yes by the VRP because n can never be negative because again signed type
overflow is undefined. If we do INT_MAX*2, we could still get INT_MAX as
allowed by the C standard.
> I'd be interested to see what execution you get on your machine
> for this code.
I already know what it does. Use -fwrapv or unsigned types if you want
something which is defined for overflow.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30245