This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Infinite loop in dcraw with current GCC versions
- From: dcoffin at shell dot cybercom dot net
- To: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>, conchur at web dot de, Sven Eckelmann <sven at narfation dot org>, René Rebe ExactCODE <rene at exactcode dot com>
- Date: Fri, 27 Feb 2015 14:02:06 -0500
- Subject: Re: Infinite loop in dcraw with current GCC versions
- Authentication-results: sourceware.org; auth=none
- References: <CAESRpQDZs=EZTAj7bO5Dn8d=M8p8MuN7_s__XNatnL2BWgs9wA at mail dot gmail dot com> <CAESRpQBx7V=O-pH5Ckvt=XpJHYyEwCyZGz1HQTByqdKftQC0MQ at mail dot gmail dot com>
Manuel,
There is no "undefined behavior" here. K&R defined it
very clearly: Arrays are pointers, and square brackets are
syntactic sugar for pointer arithmetic and dereferencing:
cam_xyz[i][j] vs. *(cam_xyz + (i)*3 + (j))
Dave Coffin 2/27/2015
On Fri, Feb 27, 2015 at 07:30:31PM +0100, Manuel López-Ibáñez wrote:
> On 27 February 2015 at 19:12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> >> This sounds like a compiler bug to me. A statement
> >> of the form:
> >>
> >> for (i=0; i < 12; i++) {
> >> <code that doesn't change "i">
> >> }
> >>
> >> should never generate an infinite loop.
> >
> > If there is undefined behavior, then not only can generate an infinite
> > loop but many kinds of nasty effects. The reasons are difficult to
> > explain, but you just have to think that at some moment the code has
> > to be converted to something like:
> >
> > if(x) goto Y
> > else goto Z
> >
> > and some optimization may decide that x is always false or always true
> > (because of something that goes inside the for-loop that cannot happen
> > ever has started a possibly long chain of transformations that
> > ultimately leads to that conclusion) Voilá: infinite loop.
>
> And the above should also explain why this kind of arguments:
>
> * It was working before
> * It only happens with a particular optimization
> * It only happens with a particular version of GCC
> * It works in every machine and every compiler I have tested it
> * "I ran my last full test (over 2000 raw photos) with
> GCC 4.9.1" and it doesn't happen
>
> are not useful. Maybe by chance, at some step in the long chain of
> events, the UB did not have any bad effect, but something seemingly
> unrelated changed within that chain and suddenly you get an infinite
> loop, and this does not mean that the compiler had a bug before or has
> a bug now, only that the chain of events was and is valid as long as
> your program does not have UB.
>
> For those interested in UB, I will strongly recommend reading:
> http://www.eskimo.com/~scs/readings/undef.950321.html
>
> Cheers,
>
> Manuel.