This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/33498] [4.2/4.3 Regression] Optimizer (-O2) may convert a normal loop to infinite
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Sep 2007 08:44:24 -0000
- Subject: [Bug tree-optimization/33498] [4.2/4.3 Regression] Optimizer (-O2) may convert a normal loop to infinite
- References: <bug-33498-15115@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #11 from rguenther at suse dot de 2007-09-20 08:44 -------
Subject: Re: [4.2/4.3 Regression] Optimizer
(-O2) may convert a normal loop to infinite
On Wed, 19 Sep 2007, rakdver at gcc dot gnu dot org wrote:
> ------- Comment #8 from rakdver at gcc dot gnu dot org 2007-09-19 16:56 -------
> t #2)
> > Technically the testcase invokes undefined behavior because 'val' overflows
> > during loop execution. Practically from a QOI point of view the undefinedness
> > should not propagate to the loop exit test (though GCCs behavior is certainly
> > standard conforming here). A nice example for what undefined behavior can
> > cause though ;)
> >
> > So, not sure if invalid or not.
>
> What happens is that ivopts decide to use val as the variable to use in the
> exit compare; they compute what its final value will be (67305984), and replace
> the exit test by val != 67305984.
>
> There is not much I can do with that in ivopts. I could make ivopts avoid
> preserving signed variables appearing in the source code that provably
> overflow; but I do not think we want to introduce this kind of hacks to handle
> code with undefined behavior.
I see. I thought we might be able to recognize the overflow in computing
the final value of val and as val is signed, not use that for the exit
test. Or simply give up in computing the final value for val if it
invokes signed overflow. I agree the code invokes undefined behavior,
just from a QOI perspective it might be nice to not produce the endless
loop here ;)
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33498