This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/30245] -O2 generates bad code



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]